Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization

2016-12-02 Thread Masashi Honma

On 2016/12/03 06:13, Bob Copeland wrote:

On Fri, Dec 02, 2016 at 12:07:18PM -0800, Thomas Pedersen wrote:


# Rejected by linux wireless ML. This is resubmission.

thomas and Bob, Thanks for comments.

> 802.11-2012 13.13.2.2.3:
> The mesh STA checks if the transmitter of the Beacon frame or Probe
> Response frame is in the
> process of the TBTT adjustment (see 13.13.4.4.3).

There are two functionalities.

1) 13.13.2.2 Neighbor offset synchronization method
2) 13.13.4.4 TBTT adjustment

The ifmsh->adjusting_tbtt flag implements "TBTT Adjusting field" in the
Mesh Configuration field.

The flag is updated by 2).
13.13.4.4.3 TBTT scanning and adjustment procedures:
The mesh STA shall set the TBTT Adjusting field in the Mesh
Configuration element to 1 in order to announce that the TBTT
adjustment procedure is ongoing.

And the flag is refered by 1) as you said.

The purpose of the flag is to prevent 1) while 2) is ongoing.

In other words, 1) has only read access authority to the flag. However,
previous code updated the flag in 1). In addition, there is no code for
2). So I just remove the invalid accessing codes.

Masashi Honma.


Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures

2016-12-02 Thread Bhumika Goyal
On Sat, Dec 3, 2016 at 2:09 AM, Larry Finger  wrote:
> On 12/02/2016 03:50 AM, Bhumika Goyal wrote:
>>
>> The structures rate_control_ops are only passed as an argument to the
>> functions ieee80211_rate_control_{register/unregister}. This argument is
>> of type const, so rate_control_ops having this property can also be
>> declared as const.
>> Done using Coccinelle:
>>
>> @r1 disable optional_qualifier @
>> identifier i;
>> position p;
>> @@
>> static struct rate_control_ops i@p = {...};
>>
>> @ok1@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_register(&i@p)
>>
>> @ok2@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_unregister(&i@p)
>>
>> @bad@
>> position p!={r1.p,ok1.p,ok2.p};
>> identifier r1.i;
>> @@
>> i@p
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> static
>> +const
>> struct rate_control_ops i={...};
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> +const
>> struct rate_control_ops i;
>>
>> File size before:
>>textdata bss dec hex filename
>>1991 104   02095 82f wireless/realtek/rtlwifi/rc.o
>>
>> File size after:
>>textdata bss dec hex filename
>>2095   0   02095 wireless/realtek/rtlwifi/rc.o
>>
>> Signed-off-by: Bhumika Goyal 
>> ---
>>  drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> index ce8621a..107c13c 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/rc.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
>> @@ -284,7 +284,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
>> kfree(rate_priv);
>>  }
>>
>> -static struct rate_control_ops rtl_rate_ops = {
>> +static const struct rate_control_ops rtl_rate_ops = {
>> .name = "rtl_rc",
>> .alloc = rtl_rate_alloc,
>> .free = rtl_rate_free,
>>
>
> The content of your patch is OK; however, your subject is not. By
> convention, "net: wireless: realtek:" is assumed. We do, however, include
> "rtlwifi:" to indicate which part of drivers/net/wireless/realtek/ is
> referenced.
>
Ok, I will send a v2 with the correct subject. Thanks for the input.

Thanks,
Bhumika

> NACK
>
> Larry
>


Re: ath10k firmware crashes in mesh mode on QCA9880

2016-12-02 Thread Benjamin Morgan

Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:

[  131.568989] ath10k_pci :01:00.0: firmware crashed! (uuid 
1838347e-9380-4a26-ac9d-2963ee95968b)
[  131.578124] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub :
[  131.587491] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 1
[  131.600521] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58 api 5 
features no-p2p,raw-mode,mfp crc32 e1af076f
[  131.610899] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[  131.618325] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1

[  131.629965] ath10k_pci :01:00.0: firmware register dump:
[  131.635728] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A45AF 0x00955B31
[  131.643761] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130 
0x0002 0x00439E98
[  131.651806] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[  131.659852] ath10k_pci :01:00.0: [12]: 0x0009 0x 
0x009A3550 0x009A355E
[  131.667892] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A31D6 
0x 0x
[  131.675936] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4 
0x0040AC60 0x0040AC09
[  131.683968] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24 
0x0040 0xC09A45AF
[  131.692013] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84 
0x0044110C 0x00442074
[  131.700056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4 
0x0044110C 0x00407120
[  131.708100] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4 
0x0040AC14 0x1580
[  131.716143] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04 
0x009C6458 0x004436CC
[  131.724175] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64 
0x004208FC 0x00439E4C
[  131.732220] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84 
0x004208FC 0x00425874
[  131.740263] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4 
0x00424FE8 0x0002
[  131.748306] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14 
0x0004 0x004039D0

[  131.857076] ieee80211 phy0: Hardware restart was requested
[  131.862705] ath10k_pci :01:00.0: failed to synchronize monitor 
vdev 1 stop: -143

[  131.870594] ath10k_pci :01:00.0: failed to stop monitor vdev: -143

~Benjamin

On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote:

Hi,

On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:

When we try to transmit traffic (ping) between two meshed ath10k
devices running latest lede we keep experiencing ath10k firmware
crashes. This seems to only happen when running in 802.11n/ac mode
but not in 802.11a/g mode. Also, from the station dumps it appears
that management traffic is flowing between the devices, however when
we try to send unicast data traffic the firmware crashes
immediately.

[shafi] Did you get a chance to try with the below firmware as well
https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58


Platform: Archer C7 AC1750 v2
Software Image: LEDE (HEAD, r2299) Commit: 
https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58

Crypto: wpa_supplicant
wpa_supplicant-wlan0.conf
network={
ssid="bmorgan_lede_mesh"
key_mgmt=SAE
mode=5
frequency=5180
psk="meshpassword"
}

Backports Verstion:
[9.818007] Loading modules backported from Linux version
wt-2016-10-03-1-g6fcb1a6
[9.825736] Backport generated by backports.git
backports-20160324-9-g0e38f5c

​​Ath10k Initialization on Station A (dmesg)
[9.896715] PCI: Enabling device :01:00.0 ( -> 0002)
[9.902622] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode
1 irq_mode 0 reset_mode 0
[   10.123734] ath10k_pci :01:00.0: Direct firmware load for
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
[   10.134620] ath10k_pci :01:00.0: Falling back to user helper
[   10.287680] firmware ath10k!pre-cal-pci-:01:00.0.bin:
firmware_loading_store: map pages failed
[   10.622789] ath10k_pci :01:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043202ff sub :
[   10.632184] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   10.645231] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54
api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
[   10.655660] ath10k_pci :01:00.0: Direct firmware load for
ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[   10.666264] ath10k_pci :01:00.0: Falling back to user helper
[   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
firmware_loading_store: map pages failed
[   11.011123] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[   12.155224] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
2 cal file max-sta 128 raw 0 hwcrypto 1

Station A (wlan0):
18:A6:F7:23:6E:66
10.230.5.41

Station B (wlan0):
18:a6:f7:26:0f:21
10.230.5.42

Station Dump on Station A before ping:
Station 18:a6:f7

????????????????

2016-12-02 Thread ZEUM
ZEUMlinux-wireless

ѧÏḞÃæÊÔÎÊÌâÉèỳÆṁÄṠùḟẅÀíÂÛẃÍṖẄṖẀ
39

???.xls
Description: application/msexcel


[PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs

2016-12-02 Thread Jouni Malinen
From: vamsi krishna 

Enhance sched scan to support option of finding a better BSS while in
connected state. Firmware scans the medium and reports when it finds a
known BSS which has better RSSI than the current connected BSS. New
attributes to specify the relative RSSI (compared to the current BSS)
are added to the sched scan to implement this.

Signed-off-by: vamsi krishna 
Signed-off-by: Jouni Malinen 
---
 include/net/cfg80211.h   | 19 +++
 include/uapi/linux/nl80211.h | 18 ++
 net/wireless/nl80211.c   | 29 +++--
 3 files changed, 64 insertions(+), 2 deletions(-)

v2: address comments from Luca, Arend, and Johannes

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef42749..dcdd0c4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1626,6 +1626,22 @@ struct cfg80211_sched_scan_plan {
  * cycle.  The driver may ignore this parameter and start
  * immediately (or at any other time), if this feature is not
  * supported.
+ * @relative_rssi: Relative RSSI threshold in dB to restrict scan result
+ * reporting in connected state to cases where a matching BSS is determined
+ * to have better RSSI than the current connected BSS. The relative RSSI
+ * threshold values are ignored in disconnected state.
+ * @relative_rssi_5g_pref: The amount of RSSI preference in dB that is given to
+ * a 5 GHz BSS over 2.4 GHz BSS while looking for better BSSs in connected
+ * state. A negative value can be passed if 2.4 GHz band should be given
+ * priority to 5 GHz band.
+ * If the current connected BSS is in the 2.4 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by @relative_rssi
+ * and other BSSs in the 5 GHz band to be reported should have better RSSI
+ * by (@relative_rssi - @relative_rssi_5g_pref).
+ * If the current connected BSS is in the 5 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by
+ * (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
+ * band to be reported should have better RSSI by by @relative_rssi.
  */
 struct cfg80211_sched_scan_request {
struct cfg80211_ssid *ssids;
@@ -1645,6 +1661,9 @@ struct cfg80211_sched_scan_request {
u8 mac_addr[ETH_ALEN] __aligned(2);
u8 mac_addr_mask[ETH_ALEN] __aligned(2);
 
+   s8 relative_rssi;
+   s8 relative_rssi_5g_pref;
+
/* internal */
struct wiphy *wiphy;
struct net_device *dev;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..fc29bdb 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1980,6 +1980,17 @@ enum nl80211_commands {
  * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
also
  * used in various commands/events for specifying the BSSID.
  *
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
+ * other BSSs has to be better than the current connected BSS so that they
+ * get reported to user space. This will give an opportunity to userspace
+ * to consider connecting to other matching BSSs which have better RSSI
+ * than the current connected BSS by using an offloaded operation to avoid
+ * unnecessary wakeups.
+ *
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF: The amount of RSSI 
preference
+ * to be given to 5 GHz APs over 2.4 GHz APs while searching for better
+ * BSSs than the current connected BSS.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2386,6 +2397,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_BSSID,
 
+   NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+   NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
@@ -4697,6 +4711,9 @@ enum nl80211_feature_flags {
  * configuration (AP/mesh) with VHT rates.
  * @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
  * with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI: The driver supports 
sched_scan
+ * for reporting BSSs with better RSSI than the current connected BSS
+ * (%NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI).
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4712,6 +4729,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+   NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wi

[PATCH v2 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req

2016-12-02 Thread Jouni Malinen
From: Vamsi Krishna 

NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
and the random MAC address to be used when privacy is enabled. When both
the features are enabled, both the BSSID and the local MAC address were
getting same value causing Probe Request frames to go with unintended
DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
attribute to set the specific BSSID (which was the more recent addition
in cfg80211) for a scan.

Backwards compatibility with old userspace software is maintained to
some extent by allowing NL80211_ATTR_MAC to be used to set the specific
BSSID when scanning without enabling random MAC address use.

Scanning with random source MAC address was introduced by commit
ad2b26abc157 ("cfg80211: allow drivers to support random MAC addresses
for scan") and the issue was introduced with the addition of the second
user for the same attribute in commit 818965d39177 ("cfg80211: Allow a
scan request for a specific BSSID").

Fixes: 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID")
Signed-off-by: Vamsi Krishna 
Signed-off-by: Jouni Malinen 
---
 include/uapi/linux/nl80211.h |  7 ++-
 net/wireless/nl80211.c   | 16 +++-
 2 files changed, 21 insertions(+), 2 deletions(-)

v2: address comments from Luca and Johannes

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 259c9c7..6b76e3b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -323,7 +323,7 @@
  * @NL80211_CMD_GET_SCAN: get scan results
  * @NL80211_CMD_TRIGGER_SCAN: trigger a new scan with the given parameters
  * %NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the
- * probe requests at CCK rate or not. %NL80211_ATTR_MAC can be used to
+ * probe requests at CCK rate or not. %NL80211_ATTR_BSSID can be used to
  * specify a BSSID to scan for; if not included, the wildcard BSSID will
  * be used.
  * @NL80211_CMD_NEW_SCAN_RESULTS: scan notification (as a reply to
@@ -1977,6 +1977,9 @@ enum nl80211_commands {
  * @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Indicates whether or not 
multicast
  * packets should be send out as unicast to all stations (flag attribute).
  *
+ * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
also
+ * used in various commands/events for specifying the BSSID.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2381,6 +2384,8 @@ enum nl80211_attrs {
 
NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED,
 
+   NL80211_ATTR_BSSID,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e4f718e..7762231 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -404,6 +404,7 @@ enum nl80211_multicast_groups {
.len = FILS_MAX_KEK_LEN },
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
+   [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
 };
 
 /* policy for the key attributes */
@@ -6703,7 +6704,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, 
struct genl_info *info)
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
 
-   if (info->attrs[NL80211_ATTR_MAC])
+   /* Initial implementation used NL80211_ATTR_MAC to set the specific
+* BSSID to scan for. This was problematic because that same attribute
+* was already used for another purpose (local random MAC address). The
+* NL80211_ATTR_BSSID attribute was added to fix this. For backwards
+* compatibility with older userspace components, also use the
+* NL80211_ATTR_MAC value here if it can be determined to be used for
+* the specific BSSID use case instead of the random MAC address
+* (NL80211_ATTR_SCAN_FLAGS is used to enable random MAC address use).
+*/
+   if (info->attrs[NL80211_ATTR_BSSID])
+   memcpy(request->bssid,
+  nla_data(info->attrs[NL80211_ATTR_BSSID]), ETH_ALEN);
+   else if (!(request->flags & NL80211_SCAN_FLAG_RANDOM_ADDR) &&
+info->attrs[NL80211_ATTR_MAC])
memcpy(request->bssid, nla_data(info->attrs[NL80211_ATTR_MAC]),
   ETH_ALEN);
else
-- 
1.9.1



[PATCH] adm80211: add checks for dma mapping errors

2016-12-02 Thread Alexey Khoroshilov
The driver does not check if mapping dma memory succeed.
The patch adds the checks and failure handling.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/net/wireless/admtek/adm8211.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/admtek/adm8211.c 
b/drivers/net/wireless/admtek/adm8211.c
index 70ecd82d674d..2b4a3eb38dfa 100644
--- a/drivers/net/wireless/admtek/adm8211.c
+++ b/drivers/net/wireless/admtek/adm8211.c
@@ -413,6 +413,13 @@ static void adm8211_interrupt_rci(struct ieee80211_hw *dev)
   skb_tail_pointer(newskb),
   RX_PKT_SIZE,
   PCI_DMA_FROMDEVICE);
+   if (pci_dma_mapping_error(priv->pdev,
+  priv->rx_buffers[entry].mapping)) {
+   priv->rx_buffers[entry].skb = NULL;
+   dev_kfree_skb(newskb);
+   skb = NULL;
+   /* TODO: update rx dropped stats */
+   }
} else {
skb = NULL;
/* TODO: update rx dropped stats */
@@ -1450,6 +1457,12 @@ static int adm8211_init_rings(struct ieee80211_hw *dev)
  
skb_tail_pointer(rx_info->skb),
  RX_PKT_SIZE,
  PCI_DMA_FROMDEVICE);
+   if (pci_dma_mapping_error(priv->pdev, rx_info->mapping)) {
+   dev_kfree_skb(rx_info->skb);
+   rx_info->skb = NULL;
+   break;
+   }
+
desc->buffer1 = cpu_to_le32(rx_info->mapping);
desc->status = cpu_to_le32(RDES0_STATUS_OWN | RDES0_STATUS_SQL);
}
@@ -1613,7 +1626,7 @@ static void adm8211_calc_durations(int *dur, int *plcp, 
size_t payload_len, int
 }
 
 /* Transmit skb w/adm8211_tx_hdr (802.11 header created by hardware) */
-static void adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb,
+static int adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb,
   u16 plcp_signal,
   size_t hdrlen)
 {
@@ -1625,6 +1638,8 @@ static void adm8211_tx_raw(struct ieee80211_hw *dev, 
struct sk_buff *skb,
 
mapping = pci_map_single(priv->pdev, skb->data, skb->len,
 PCI_DMA_TODEVICE);
+   if (pci_dma_mapping_error(priv->pdev, mapping))
+   return -ENOMEM;
 
spin_lock_irqsave(&priv->lock, flags);
 
@@ -1657,6 +1672,8 @@ static void adm8211_tx_raw(struct ieee80211_hw *dev, 
struct sk_buff *skb,
 
/* Trigger transmit poll */
ADM8211_CSR_WRITE(TDR, 0);
+
+   return 0;
 }
 
 /* Put adm8211_tx_hdr on skb and transmit */
@@ -1710,7 +1727,10 @@ static void adm8211_tx(struct ieee80211_hw *dev,
 
txhdr->retry_limit = info->control.rates[0].count;
 
-   adm8211_tx_raw(dev, skb, plcp_signal, hdrlen);
+   if (adm8211_tx_raw(dev, skb, plcp_signal, hdrlen)) {
+   /* Drop packet */
+   ieee80211_free_txskb(dev, skb);
+   }
 }
 
 static int adm8211_alloc_rings(struct ieee80211_hw *dev)
-- 
2.7.4



Re: [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs

2016-12-02 Thread Malinen, Jouni
On Fri, Nov 25, 2016 at 11:21:15AM +0200, Luca Coelho wrote:
> On Thu, 2016-11-24 at 00:07 +0200, Jouni Malinen wrote:
> > From: vamsi krishna 
> > @@ -9670,6 +9689,15 @@ static int nl80211_send_wowlan_nd(struct sk_buff 
> > *msg,
> > if (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_DELAY, req->delay))
> > return -ENOBUFS;
> >  
> > +   if (wiphy_ext_feature_isset(
> > +   wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS) &&
> > +   (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
> > +req->relative_rssi) ||
> > +nla_put_u32(msg,
> > +NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
> > +req->relative_rssi_5g_pref)))
> > +   return -ENOBUFS;
> > +
> 
> Why did you add this to nl80211_send_wowlan_nd() function?

Rest of the feedback will be addressed in PATCH v2, but I'm not sure
what to do with this part. I don't think we have any use case for this,
i.e., the addition here for NL80211_CMD_GET_WOWLAN response attributes
is based on how other sched_scan attributes were already included in the
response. Any new attribute atted to nl80211_parse_sched_scan() (like
these two new attributes) get parsed into
rdev->wiphy.wowlan_config->nd_config in nl80211_wowlan_nd(), so they can
end up being set here when using NL80211_CMD_SET_WOWLAN.
 
-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization

2016-12-02 Thread Bob Copeland
On Fri, Dec 02, 2016 at 12:07:18PM -0800, Thomas Pedersen wrote:
> On Wed, Nov 30, 2016 at 2:44 PM, Masashi Honma  
> wrote:
> > mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
> > framework ([1] 13.13.2 Extensible synchronization framework). It shall
> > not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
> > Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
> > collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
> > procedures for detail). So this patch remove the flag operations.
> 
> 802.11-2012 13.13.2.2.3:
[snip]
> so, no? I think we need to indicate a TSF adjustment is taking place.

I think so too.

I must ask, what is the prompt for removing it, are you (Masashi)
trying to implement MBCA and this is interfering?

-- 
Bob Copeland %% http://bobcopeland.com/


[PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT

2016-12-02 Thread Andrew Zaborowski
Disconnect or deauthenticate when the owning socket is closed if this
flag has been supplied to CMD_CONNECT, CMD_AUTHENTICATE or CMD_ASSOCIATE.

Signed-off-by: Andrew Zaborowski 
---
 include/net/cfg80211.h   |  5 +
 include/uapi/linux/nl80211.h |  3 +++
 net/wireless/core.c  | 23 +++
 net/wireless/mlme.c  |  4 
 net/wireless/nl80211.c   | 29 -
 net/wireless/sme.c   |  4 
 6 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bd19faa..413f5b5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3764,6 +3764,8 @@ struct cfg80211_cached_keys;
  * @conn: (private) cfg80211 software SME connection state machine data
  * @connect_keys: (private) keys to set after connection is established
  * @conn_bss_type: connecting/connected BSS type
+ * @conn_owner_nlportid: (private) connection owner socket port ID
+ * @disconnect_wk: (private) auto-disconnect work
  * @ibss_fixed: (private) IBSS is using fixed BSSID
  * @ibss_dfs_possible: (private) IBSS may change to a DFS channel
  * @event_list: (private) list for internal event processing
@@ -3795,6 +3797,9 @@ struct wireless_dev {
struct cfg80211_conn *conn;
struct cfg80211_cached_keys *connect_keys;
enum ieee80211_bss_type conn_bss_type;
+   u32 conn_owner_nlportid;
+
+   struct work_struct disconnect_wk;
 
struct list_head event_list;
spinlock_t event_lock;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 56368e9..12f41b0 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1788,6 +1788,9 @@ enum nl80211_commands {
  * and remove functions. NAN notifications will be sent in unicast to that
  * socket. Without this attribute, any socket can add functions and the
  * notifications will be sent to the %NL80211_MCGRP_NAN multicast group.
+ * If set during one of: %NL80211_CMD_AUTHENTICATE, %NL80211_CMD_ASSOCIATE
+ * or %NL80211_CMD_CONNECT the station will deauthenticate when the
+ * socket is closed.
  *
  * @NL80211_ATTR_TDLS_INITIATOR: flag attribute indicating the current end is
  * the TDLS link initiator.
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 8201e6d..98db6b2 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -357,6 +357,26 @@ static void cfg80211_sched_scan_stop_wk(struct work_struct 
*work)
rtnl_unlock();
 }
 
+static void cfg80211_disconnect_wk(struct work_struct *work)
+{
+   struct cfg80211_registered_device *rdev;
+   struct wireless_dev *wdev;
+
+   wdev = container_of(work, struct wireless_dev, disconnect_wk);
+   rdev = wiphy_to_rdev(wdev->wiphy);
+
+   if (!wdev->netdev)
+   return;
+
+   wdev_lock(wdev);
+
+   if (wdev->conn_owner_nlportid)
+   cfg80211_disconnect(rdev, wdev->netdev,
+   WLAN_REASON_DEAUTH_LEAVING, true);
+
+   wdev_unlock(wdev);
+}
+
 /* exported functions */
 
 struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
@@ -1117,6 +1137,8 @@ static int cfg80211_netdev_notifier_call(struct 
notifier_block *nb,
 wdev->iftype == NL80211_IFTYPE_ADHOC) && !wdev->use_4addr)
dev->priv_flags |= IFF_DONT_BRIDGE;
 
+   INIT_WORK(&wdev->disconnect_wk, cfg80211_disconnect_wk);
+
nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
break;
case NETDEV_GOING_DOWN:
@@ -1205,6 +1227,7 @@ static int cfg80211_netdev_notifier_call(struct 
notifier_block *nb,
 #ifdef CONFIG_CFG80211_WEXT
kzfree(wdev->wext.keys);
 #endif
+   flush_work(&wdev->disconnect_wk);
}
/*
 * synchronise (so that we won't find this netdev
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index cbb48e2..eaf2d1d 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -130,6 +130,8 @@ void cfg80211_auth_timeout(struct net_device *dev, const u8 
*addr)
 
nl80211_send_auth_timeout(rdev, dev, addr, GFP_KERNEL);
cfg80211_sme_auth_timeout(wdev);
+
+   wdev->conn_owner_nlportid = 0;
 }
 EXPORT_SYMBOL(cfg80211_auth_timeout);
 
@@ -146,6 +148,8 @@ void cfg80211_assoc_timeout(struct net_device *dev, struct 
cfg80211_bss *bss)
 
cfg80211_unhold_bss(bss_from_pub(bss));
cfg80211_put_bss(wiphy, bss);
+
+   wdev->conn_owner_nlportid = 0;
 }
 EXPORT_SYMBOL(cfg80211_assoc_timeout);
 
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c510810..ccd74c7 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7818,6 +7818,10 @@ static int nl80211_authenticate(struct sk_buff *skb, 
struct genl_info *info)
 key.p.key, key.p.key_len, key.idx,
   

Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures

2016-12-02 Thread Larry Finger

On 12/02/2016 03:50 AM, Bhumika Goyal wrote:

The structures rate_control_ops are only passed as an argument to the
functions ieee80211_rate_control_{register/unregister}. This argument is
of type const, so rate_control_ops having this property can also be
declared as const.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct rate_control_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
@@
ieee80211_rate_control_register(&i@p)

@ok2@
identifier r1.i;
position p;
@@
ieee80211_rate_control_unregister(&i@p)

@bad@
position p!={r1.p,ok1.p,ok2.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct rate_control_ops i={...};

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct rate_control_ops i;

File size before:
   textdata bss dec hex filename
   1991 104   02095 82f wireless/realtek/rtlwifi/rc.o

File size after:
   textdata bss dec hex filename
   2095   0   02095 wireless/realtek/rtlwifi/rc.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c 
b/drivers/net/wireless/realtek/rtlwifi/rc.c
index ce8621a..107c13c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -284,7 +284,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
kfree(rate_priv);
 }

-static struct rate_control_ops rtl_rate_ops = {
+static const struct rate_control_ops rtl_rate_ops = {
.name = "rtl_rc",
.alloc = rtl_rate_alloc,
.free = rtl_rate_free,



The content of your patch is OK; however, your subject is not. By convention, 
"net: wireless: realtek:" is assumed. We do, however, include "rtlwifi:" to 
indicate which part of drivers/net/wireless/realtek/ is referenced.


NACK

Larry



Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization

2016-12-02 Thread Thomas Pedersen
On Wed, Nov 30, 2016 at 2:44 PM, Masashi Honma  wrote:
> mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
> framework ([1] 13.13.2 Extensible synchronization framework). It shall
> not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
> Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
> collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
> procedures for detail). So this patch remove the flag operations.

802.11-2012 13.13.2.2.3:

The mesh STA checks if the transmitter of the Beacon frame or Probe
Response frame is in the
process of the TBTT adjustment (see 13.13.4.4.3). If the received
frame contains the Mesh
Configuration element and the TBTT Adjusting subfield in the Mesh
Configuration field is 1, the
mesh STA shall invalidate the T offset value for this neighbor STA and
shall not perform the
following steps.

so, no? I think we need to indicate a TSF adjustment is taking place.

-- 
thomas


Re: pull-request: wireless-drivers-next 2016-12-01

2016-12-02 Thread David Miller
From: Kalle Valo 
Date: Thu, 01 Dec 2016 20:33:37 +0200

> here's another pull request for net-next. Nothing special to mention
> about, the details are in the signed tag below.
> 
> This time there's a trivial conflict in
> drivers/net/wireless/ath/ath10k/mac.c:
> 
> <<< HEAD
>   ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
> ===
>   ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
 d5fb3a138048798ce4cc4b4ced47d07d1794c577
> 
> We want to have both flags enabled in ath10k.
> 
> I'm planning to submit at least one more pull request, if Linus gives us
> one more week I might send even two. For example there are patches to
> convert wcn36xx to use the real SMD bus subsystem but they depend on few
> arm-soc patches. I'll send a separate email about that, they are not
> part of this pull request.
> 
> Please let me know if there are any problems.

Pulled, thanks so much for the heads up about the ath10k merge conflict.


Non-working mwifiex_sdio with SD8897

2016-12-02 Thread Takashi Iwai
Hi,

we've got an Intel Cherry Trail-based system with Marvell SD8897 chip
over MMC (sdhci), and WiFi / BT always fails at starting (or better to
say, it never worked properly).

For avoiding the race between WiFi and BT, I blacklisted btmrvl_sdio,
so let's concentrate only on mwifiex_sdio now.

At the beginning of the driver loading, it looks fine:

 mwifiex_sdio mmc1:0001:1: info: FW download over, size 802164 bytes
 mwifiex_sdio mmc1:0001:1: WLAN FW is active
 mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) 
 mwifiex_sdio mmc1:0001:1: driver_version = mwifiex 1.0 (15.68.7.p77) 
 cfg80211: Regulatory domain changed to country: US
 .

Then it gets a timeout

 mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0x107, 
act = 0x0
 mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0
 mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0
 mwifiex_sdio mmc1:0001:1: is_cmd_timedout = 1
 mwifiex_sdio mmc1:0001:1: num_tx_timeout = 0
 mwifiex_sdio mmc1:0001:1: last_cmd_index = 4
 mwifiex_sdio mmc1:0001:1: last_cmd_id: 1e 00 0c 01 1e 00 20 00 07 01
 mwifiex_sdio mmc1:0001:1: last_cmd_act: 00 00 01 00 00 00 08 00 00 00
 mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 3
 mwifiex_sdio mmc1:0001:1: last_cmd_resp_id: 1e 80 0c 81 1e 80 20 80 20 80
 mwifiex_sdio mmc1:0001:1: last_event_index = 1
 mwifiex_sdio mmc1:0001:1: last_event: 00 00 0b 00 00 00 00 00 00 00
 mwifiex_sdio mmc1:0001:1: data_sent=0 cmd_sent=0
 mwifiex_sdio mmc1:0001:1: ps_mode=1 ps_state=1
 mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump start===
 mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77) 
 mwifiex_sdio mmc1:0001:1: SDIO register dump start
 mwifiex_sdio mmc1:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 02 00 02 03 00 
 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0x0-0xb): 02 ff c3 40 00 00 00 00 ff ff 
ff ff 
 mwifiex_sdio mmc1:0001:1: SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c 
(0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00 
 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 6c 00 10 00 3f 36 36 
02 20 
 mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 76 00 1a 00 3f 36 36 
02 20 
 mwifiex_sdio mmc1:0001:1: SDIO register dump end
 mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump end===
 mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump start ==
 mwifiex_sdio mmc1:0001:1: Ignore scan. Card removed or firmware in bad state
 mwifiex_sdio mmc1:0001:1: scan failed: -14
 mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump end ==
 mwifiex_sdio mmc1:0001:1: == mwifiex dump information to 
/sys/class/devcoredump start
 mwifiex_sdio mmc1:0001:1: == mwifiex dump information to 
/sys/class/devcoredump end

And the reset fails as well:

 mwifiex_sdio mmc1:0001:1: info: shutdown mwifiex...
 mwifiex_sdio mmc1:0001:1: PREP_CMD: card is removed
 mmc1: tried to reset card
 mwifiex_sdio mmc1:0001:1: failed to enable function


I can give the output with CONFIG_MMC_DEBUG and dyndbg for mwifiex*,
but the full log is way too big to post, as the system is eMMC and it
contains lots of noises.  In case it helps, the log snippet before the
timeout is like:

 [   42.367403] mwifiex_sdio mmc1:0001:1: bgscan already stopped!
 [   42.398871] mmc1: starting CMD53 arg 93000100 flags 01b5
 [   42.398880] mmc1: blksz 256 blocks 1 flags 0100 tsac 1000 ms nsac 0
 [   42.399136] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.400415] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.401787] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.403044] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.404498] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.405874] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.407192] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.408703] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.410229] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.411464] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.412754] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.414211] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.415365] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.416635] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.417968] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.419163] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.420439] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.421891] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.423206] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.424531] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.425974] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.427268] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x0020
 [   42.428575] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x

[PATCH] net: wireless: realtek: constify rate_control_ops structures

2016-12-02 Thread Bhumika Goyal
The structures rate_control_ops are only passed as an argument to the
functions ieee80211_rate_control_{register/unregister}. This argument is
of type const, so rate_control_ops having this property can also be 
declared as const.
Done using Coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct rate_control_ops i@p = {...};

@ok1@
identifier r1.i;
position p;
@@
ieee80211_rate_control_register(&i@p)

@ok2@
identifier r1.i;
position p;
@@
ieee80211_rate_control_unregister(&i@p)

@bad@
position p!={r1.p,ok1.p,ok2.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct rate_control_ops i={...};

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct rate_control_ops i;

File size before:
   textdata bss dec hex filename
   1991 104   02095 82f wireless/realtek/rtlwifi/rc.o

File size after:
   textdata bss dec hex filename
   2095   0   02095 wireless/realtek/rtlwifi/rc.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c 
b/drivers/net/wireless/realtek/rtlwifi/rc.c
index ce8621a..107c13c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -284,7 +284,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
kfree(rate_priv);
 }
 
-static struct rate_control_ops rtl_rate_ops = {
+static const struct rate_control_ops rtl_rate_ops = {
.name = "rtl_rc",
.alloc = rtl_rate_alloc,
.free = rtl_rate_free,
-- 
1.9.1