Re: wireless-drivers: random cleanup patches piling up

[Julian Calaby]

Hi Kalle,

On Mon, Feb 1, 2016 at 7:21 PM, Kalle Valo  wrote:
> Sudip Mukherjee  writes:
>
>> Sure, I am starting that way. I checked in patchwork and I do not see
>> any checkpatch related patch pending (except staging, which Greg will
>> handle). I think you must have cleared all of them.
>
> They are in deferred state. The search functionality in patchwork is not
> that intuitive and they are not easy to find so here's a direct link:
>
> https://patchwork.kernel.org/project/linux-wireless/list/?state=10=date

I'm currently going through that list and producing a bundle of
"applyable" patches.

My criteria is:
1. The change is sane.
2. It's either obviously correct, I can review it, or someone else has
reviewed or acked it.
3. No changes other than rebasing and fixing commit messages are
required to apply it.

Some of these patches need work on their commit messages, some are
complicated enough that I feel I should be providing review notes so
someone else can double check my review, and all of them should be
rebased and compile tested. Also, some are controversial, so I'll be
segregating them from the main set.

How would you like me to communicate this list to you? I'm happy to
provide branches you can pull from or I could just post updated
versions to the list and give reviewed-by tags to those that don't
need more work.

Every patch will get an email on linux-wireless regardless.

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

rtl8xxxu 4.4.5(from f23): I get a panic adding a new device to the driver

[Xose Vazquez Perez]

Hi,

If I do:
# echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id

I get:
---dmesg---
usbcore: registered new interface driver rtl8xxxu
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] rtl8xxxu_probe+0x810/0x22a0 [rtl8xxxu]
PGD 0
Oops:  [#1] SMP
Modules linked in: rtl8xxxu ccm snd_seq_dummy snd_seq_oss snd_seq_midi_event 
snd_pcm_oss snd_mixer_oss arc4 intel_rapl iosf_mbi x86_pkg_temp_thermal 
coretemp kvm_intel kvm ath9k ath9k_common ath9k_hw
irqbypass ath crct10dif_pclmul i915 crc32_pclmul crc32c_intel iTCO_wdt 
iTCO_vendor_support mac80211 snd_hda_codec_realtek cfg80211 
snd_hda_codec_generic snd_usb_audio i2c_i801 snd_hda_intel
snd_hda_codec snd_hda_core snd_usbmidi_lib snd_rawmidi snd_hwdep snd_seq ses 
video i2c_algo_bit snd_seq_device drm_kms_helper enclosure lpc_ich drm snd_pcm 
rfkill snd_timer mei_me snd mei soundcore
shpchp tpm_tis tpm binfmt_misc hid_logitech_hidpp hid_logitech_dj serio_raw 
r8169 mii fjes uas usb_storage [last unloaded: rtlwifi]
CPU: 0 PID: 1233 Comm: bash Not tainted 4.4.5-300.fc23.x86_64 #1
Hardware name: Hewlett-Packard p6-2004es/2ABF, BIOS 7.16 03/23/2012
task: 88022d34 ti: 8800b5c1 task.ti: 8800b5c1
RIP: 0010:[] [] rtl8xxxu_probe+0x810/0x22a0 
[rtl8xxxu]
RSP: 0018:8800b5c13bc0 EFLAGS: 00010286
RAX:  RBX: 006a RCX: 5a32
RDX: 5a31 RSI:  RDI: 8802346bb4c0
RBP: 8800b5c13c70 R08: 0001a1e0 R09: 81586bbb
R10: ea0002d65380 R11:  R12: 00bf
R13: 00ff R14: 8802346bb4c0 R15: 00be
FS: 7fe567227700() GS:88023f40() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2:  CR3: b5d9a000 CR4: 000406f0
Stack:
88022d34 8800b5c13be8 812abf5a ffea
 8800b5c13c18 84b2960b 880232cfa090
8802346ba700 880233631400 8802346bb53e 00630246
Call Trace:
[] ? kernfs_activate+0x7a/0xe0
[] usb_probe_interface+0x1bd/0x300
[] driver_probe_device+0x222/0x490
[] __driver_attach+0x84/0x90
[] ? driver_probe_device+0x490/0x490
[] bus_for_each_dev+0x6c/0xc0
[] driver_attach+0x1e/0x20
[] usb_store_new_id+0xeb/0x1c0
[] new_id_store+0x22/0x30
[] drv_attr_store+0x25/0x30
[] sysfs_kf_write+0x37/0x40
[] kernfs_fop_write+0x11d/0x170
[] __vfs_write+0x37/0x110
[] ? __fd_install+0x33/0xe0
[] ? percpu_down_read+0x12/0x50
[] vfs_write+0xa9/0x1a0
[] SyS_write+0x55/0xc0
[] entry_SYSCALL_64_fastpath+0x12/0x71
Code: 44 89 f0 4d 89 fe 41 89 c7 66 41 81 ff ff 01 0f 86 6f ff ff ff 31 d2 be 
cf 00 00 00 4c 89 f7 e8 07 a5 ff ff 49 8b 46 10 4c 89 f7  10 85 c0 41 89 c0 
0f 85 89 03 00 00 49 8b 46 08 48 c7 c1 5b
RIP [] rtl8xxxu_probe+0x810/0x22a0 [rtl8xxxu]
RSP 
CR2: 
---[ end trace 0675ed7e0a2d84ed ]---

--rtl8192cu dmesg--
rtl8192cu: Chip version 0x10
rtl8192cu: MAC address: 00:e0:4c:07:dd:45
rtl8192cu: Board Type 0
rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
usbcore: registered new interface driver rtl8192cu
--end--

--lsusb-v--
Bus 002 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n 
WLAN Adapter
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0bda Realtek Semiconductor Corp.
  idProduct  0x8176 RTL8188CUS 802.11n WLAN Adapter
  bcdDevice2.00
  iManufacturer   1 Realtek
  iProduct2 802.11n WLAN Adapter
  iSerial 3 00e04c01
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 

Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Johannes Berg]

On Tue, 2016-03-15 at 09:10 -0700, Ben Greear wrote:
> 
> The logic I wrote is basically exactly this.  It uses the configured
> rates to specify which of the hardware's rates are allowed and
> disabled.
> 

I understand that. I just take issue with the fact that we have to
sprinkle "magic pixie dust" (in form of the override function calls)
everywhere throughout the code.

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.

[Ben Greear]

On 03/15/2016 07:15 AM, Johannes Berg wrote:

On Thu, 2016-03-10 at 09:56 -0800, Ben Greear wrote:


First, are you proposing that I make a copy of the entire  local-

hw.wiphy->bands array and store it locally in sdata?


No, I think it should be pointers there, say

sdata->bands[X] pointing to the same thing as local->hw.wiphy->bands[X]
is pointing to.

So the first patch would introduce that, and replace each and every use
of local->hw.wiphy->bands[] with sdata->bands[], if necessary
annotating the remaining ones with why they're OK and should stay.


And then, I would provide some API to modify the bands[i]->bitrates
and other variables to properly select the advertised features?


Kinda. You'd provide some kind of helper function or API to take the
local->hw.wiphy->bands[X] and duplicate it into a newly allocated
buffer, modifying it along the way, before assigning it to the per-
sdata stuff in sdata->bands[X].


I am a bit concerned about making copies (and then changing) the
driver's bitrates array.  Likely it will work with ath10k, but it
seems fragile at best.


That's an interesting point, we currently use the rate *index* a lot,
so we have to find some way of preserving that. Perhaps we need to
introduce a flag indicating a given rate is disabled?


The logic I wrote is basically exactly this.  It uses the configured rates to
specify which of the hardware's rates are allowed and disabled.

I will look more at providing some accessor functions or otherwise abstracting
it without making copies of the driver's ratesets.

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: linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c: 1851: maybe uninit data ?

[Larry Finger]

On 03/15/2016 05:50 AM, David Binderman wrote:

Hello there,

[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1851]: (error) 
Uninitialized struct member: gains.gm
[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1851]: (error) 
Uninitialized struct member: gains.pga
[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1851]: (error) 
Uninitialized struct member: gains.pad
[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1851]: (error) 
Uninitialized struct member: gains.dac

[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1853]: (error) 
Uninitialized struct member: gains.gm
[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1853]: (error) 
Uninitialized struct member: gains.pga
[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1853]: (error) 
Uninitialized struct member: gains.pad
[linux-4.5/drivers/net/wireless/broadcom/b43/phy_lp.c:1853]: (error) 
Uninitialized struct member: gains.dac

I've had a look at the code and I can't see how local structure 'gains' get 
initialised.


It does not get initialized; however, it is only used in calls to 
lpphy_papd_cal() that does nothing. Thus, no harm, no foul.


You should prepare a patch that initializes it to zero in line 1837.

Larry


--
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/2] Parsing per station rx duration for 10.4

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Peer Stats for 10.4 is enabled by Extended Resource Configuration
API (based on one of the earlier patch from Raja Mani), and parsing
of the same is based also 'stats_id' which also provides backward
compatibility with older f/w (or) ath10k by design

review help:

1. Fixed documentation related comments from Kalle / Michal
2. Fixed indentation related comments from Michal
3. Removed the check for excluding peer stats for test mode (Michal)
4. Fix checking for peer stats feature enabled

Dependency over

[PATCH v5] ath10k: Enable debugfs provision to enable Peer Stats

Mohammed Shafi Shajakhan (1):
  ath10k: Enable parsing per station rx duration for 10.4

Raja Mani (1):
  ath10k: Introduce Extended Resource Config support for 10.4

 drivers/net/wireless/ath/ath10k/core.c|   19 +-
 drivers/net/wireless/ath/ath10k/wmi-ops.h |   23 
 drivers/net/wireless/ath/ath10k/wmi.c |   54 +
 drivers/net/wireless/ath/ath10k/wmi.h |   49 +-
 4 files changed, 137 insertions(+), 8 deletions(-)

-- 
1.7.9.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/2] ath10k: Introduce Extended Resource Config support for 10.4

[Mohammed Shafi Shajakhan]

From: Raja Mani 

Add API support for Extended Resource Configuration for 10.4. This
is useful to enable new features like Peer Stats, LTEU etc if the
firmware advertises support for the service. This is also done to
provide backward compatibility with older firmware. Also for clarity
send default host platform type as 'WMI_HOST_PLATFORM_HIGH_PERF',
though this should not make any difference in functionality

Signed-off-by: Raja Mani 
Signed-off-by: Mohammed Shafi Shajakhan 
---
 drivers/net/wireless/ath/ath10k/wmi-ops.h |   23 
 drivers/net/wireless/ath/ath10k/wmi.c |   24 +
 drivers/net/wireless/ath/ath10k/wmi.h |   33 -
 3 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 32ab34e..7fb00dc 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -186,6 +186,9 @@ struct wmi_ops {
u8 enable,
u32 detect_level,
u32 detect_margin);
+   struct sk_buff *(*ext_resource_config)(struct ath10k *ar,
+  enum wmi_host_platform_type type,
+  u32 fw_feature_bitmap);
int (*get_vdev_subtype)(struct ath10k *ar,
enum wmi_vdev_subtype subtype);
 };
@@ -1330,6 +1333,26 @@ ath10k_wmi_pdev_enable_adaptive_cca(struct ath10k *ar, 
u8 enable,
 }
 
 static inline int
+ath10k_wmi_ext_resource_config(struct ath10k *ar,
+  enum wmi_host_platform_type type,
+  u32 fw_feature_bitmap)
+{
+   struct sk_buff *skb;
+
+   if (!ar->wmi.ops->ext_resource_config)
+   return -EOPNOTSUPP;
+
+   skb = ar->wmi.ops->ext_resource_config(ar, type,
+  fw_feature_bitmap);
+
+   if (IS_ERR(skb))
+   return PTR_ERR(skb);
+
+   return ath10k_wmi_cmd_send(ar, skb,
+  ar->wmi.cmd->ext_resource_cfg_cmdid);
+}
+
+static inline int
 ath10k_wmi_get_vdev_subtype(struct ath10k *ar, enum wmi_vdev_subtype subtype)
 {
if (!ar->wmi.ops->get_vdev_subtype)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index c260894..fcef9a0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -705,6 +705,7 @@ static struct wmi_cmd_map wmi_10_4_cmd_map = {
.set_cca_params_cmdid = WMI_10_4_SET_CCA_PARAMS_CMDID,
.pdev_bss_chan_info_request_cmdid =
WMI_10_4_PDEV_BSS_CHAN_INFO_REQUEST_CMDID,
+   .ext_resource_cfg_cmdid = WMI_10_4_EXT_RESOURCE_CFG_CMDID,
 };
 
 /* MAIN WMI VDEV param map */
@@ -7509,6 +7510,28 @@ static int ath10k_wmi_10_4_op_get_vdev_subtype(struct 
ath10k *ar,
return -ENOTSUPP;
 }
 
+static struct sk_buff *
+ath10k_wmi_10_4_ext_resource_config(struct ath10k *ar,
+   enum wmi_host_platform_type type,
+   u32 fw_feature_bitmap)
+{
+   struct wmi_ext_resource_config_10_4_cmd *cmd;
+   struct sk_buff *skb;
+
+   skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd));
+   if (!skb)
+   return ERR_PTR(-ENOMEM);
+
+   cmd = (struct wmi_ext_resource_config_10_4_cmd *)skb->data;
+   cmd->host_platform_config = __cpu_to_le32(type);
+   cmd->fw_feature_bitmap = __cpu_to_le32(fw_feature_bitmap);
+
+   ath10k_dbg(ar, ATH10K_DBG_WMI,
+  "host platform type :%d firmware feature bitmap :%08x\n",
+  type, fw_feature_bitmap);
+   return skb;
+}
+
 static const struct wmi_ops wmi_ops = {
.rx = ath10k_wmi_op_rx,
.map_svc = wmi_main_svc_map,
@@ -7835,6 +7858,7 @@ static const struct wmi_ops wmi_10_4_ops = {
.gen_addba_set_resp = ath10k_wmi_op_gen_addba_set_resp,
.gen_delba_send = ath10k_wmi_op_gen_delba_send,
.fw_stats_fill = ath10k_wmi_10_4_op_fw_stats_fill,
+   .ext_resource_config = ath10k_wmi_10_4_ext_resource_config,
 
/* shared with 10.2 */
.gen_request_stats = ath10k_wmi_op_gen_request_stats,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index bb42f7a..1d3e085 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -816,6 +816,7 @@ struct wmi_cmd_map {
u32 set_cca_params_cmdid;
u32 pdev_bss_chan_info_request_cmdid;
u32 pdev_enable_adaptive_cca_cmdid;
+   u32 ext_resource_cfg_cmdid;
 };
 
 /*
@@ -2665,7 +2666,32 @@ struct wmi_resource_config_10_4 {
 * 0  - This 

[PATCH 2/2] ath10k: Enable parsing per station rx duration for 10.4

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Rx duration support for per station is part of extended peer
stats, enable provision to parse the same and provide backward
compatibility based on the 'stats_id' event

Signed-off-by: Mohammed Shafi Shajakhan 
---
 drivers/net/wireless/ath/ath10k/core.c |   19 ++-
 drivers/net/wireless/ath/ath10k/wmi.c  |   30 --
 drivers/net/wireless/ath/ath10k/wmi.h  |   16 
 3 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 2389c07..5e37e61 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1534,7 +1534,8 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
ar->num_active_peers = TARGET_10_4_ACTIVE_PEERS;
ar->max_num_vdevs = TARGET_10_4_NUM_VDEVS;
ar->num_tids = TARGET_10_4_TGT_NUM_TIDS;
-   ar->fw_stats_req_mask = WMI_STAT_PEER;
+   ar->fw_stats_req_mask = WMI_10_4_STAT_PEER |
+   WMI_10_4_STAT_PEER_EXTD;
ar->max_spatial_stream = ar->hw_params.max_spatial_stream;
 
if (test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
@@ -1579,6 +1580,7 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
 int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
 {
int status;
+   u32 val;
 
lockdep_assert_held(>conf_mutex);
 
@@ -1699,6 +1701,21 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "firmware %s booted\n",
   ar->hw->wiphy->fw_version);
 
+   if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map)) {
+   val = 0;
+   if (ath10k_peer_stats_enabled(ar))
+   val = WMI_10_4_PEER_STATS;
+
+   status = ath10k_wmi_ext_resource_config(ar,
+   
WMI_HOST_PLATFORM_HIGH_PERF, val);
+   if (status) {
+   ath10k_err(ar,
+  "failed to send ext resource cfg command : 
%d\n",
+  status);
+   goto err_hif_stop;
+   }
+   }
+
status = ath10k_wmi_cmd_init(ar);
if (status) {
ath10k_err(ar, "could not send WMI init command (%d)\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index fcef9a0..7542ed8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2632,6 +2632,16 @@ void ath10k_wmi_pull_peer_stats(const struct 
wmi_peer_stats *src,
dst->peer_tx_rate = __le32_to_cpu(src->peer_tx_rate);
 }
 
+static void
+ath10k_wmi_10_4_pull_peer_stats(const struct wmi_10_4_peer_stats *src,
+   struct ath10k_fw_stats_peer *dst)
+{
+   ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
+   dst->peer_rssi = __le32_to_cpu(src->peer_rssi);
+   dst->peer_tx_rate = __le32_to_cpu(src->peer_tx_rate);
+   dst->peer_rx_rate = __le32_to_cpu(src->peer_rx_rate);
+}
+
 static int ath10k_wmi_main_op_pull_fw_stats(struct ath10k *ar,
struct sk_buff *skb,
struct ath10k_fw_stats *stats)
@@ -2925,6 +2935,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k 
*ar,
u32 num_pdev_ext_stats;
u32 num_vdev_stats;
u32 num_peer_stats;
+   u32 stats_id;
int i;
 
if (!skb_pull(skb, sizeof(*ev)))
@@ -2934,6 +2945,7 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k 
*ar,
num_pdev_ext_stats = __le32_to_cpu(ev->num_pdev_ext_stats);
num_vdev_stats = __le32_to_cpu(ev->num_vdev_stats);
num_peer_stats = __le32_to_cpu(ev->num_peer_stats);
+   stats_id = __le32_to_cpu(ev->stats_id);
 
for (i = 0; i < num_pdev_stats; i++) {
const struct wmi_10_4_pdev_stats *src;
@@ -2973,22 +2985,28 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct 
ath10k *ar,
/* fw doesn't implement vdev stats */
 
for (i = 0; i < num_peer_stats; i++) {
-   const struct wmi_10_4_peer_stats *src;
+   const struct wmi_10_4_peer_extd_stats *src;
struct ath10k_fw_stats_peer *dst;
+   int stats_len;
+   bool extd_peer_stats = !!(stats_id & WMI_10_4_STAT_PEER_EXTD);
+
+   if (extd_peer_stats)
+   stats_len = sizeof(struct wmi_10_4_peer_extd_stats);
+   else
+   stats_len = sizeof(struct wmi_10_4_peer_stats);
 
src = (void *)skb->data;
-   if (!skb_pull(skb, 

Re: [PATCH-v2] mac80211: Let VHT work on 2.4Ghz

[Johannes Berg]

On Thu, 2016-03-10 at 10:08 -0800, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> ath10k supports VHT on 2.4Ghz band.

I still don't think this is the right thing to do.

Most implementations seem to use the BRCM vendor IE to advertise "VHT"
features on 2.4 GHz, since the spec requires 5 GHz for the real ones.

The combination of ath10k with mac80211 seems to be broken in that
regard right now, since mac80211 didn't expect drivers to set the
capabilities for 2.4 GHz band.

I guess we can get away with using the regular capabilities towards
userspace, but as far as the IEs are concerned we should probably use
the BRCM ones.

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: The mac80211 softmac driver subsystem and handling of monitor interfaces

[Johannes Berg]

On Tue, 2016-03-15 at 13:01 +, Roger James wrote:
> 
> roger@dragon:~/linux-mainline$ find . -name "*.[ch]" -exec grep -n 
> IEEE80211_HW_WANT_MONITOR_VIF {} \; -print
> 1851: * @IEEE80211_HW_WANT_MONITOR_VIF: The driver would like to be 
> informed of
> 1928:IEEE80211_HW_WANT_MONITOR_VIF,
> ./include/net/mac80211.h
> 
> Is that what you meant. Nobody seems to be using it. Even mac80211 
> itself. Or am I being stupid again :-)
> 

There are macros generating the checks and setting it, so you want to
grep without the IEEE80211_HW_ prefix

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: The mac80211 softmac driver subsystem and handling of monitor interfaces

[Roger James]

On 15/03/16 12:15, Johannes Berg wrote:

On Tue, 2016-03-15 at 10:42 +, Roger James wrote:


ath/ath10k ath/ath9k (both ath9k and ath9k_htc) cw1200
brcm80211/brcmsmac

All the others seem to be doing things with NL80211_IFTYPE_MONITOR in
the vif structure. This seems contradictory.


You should look into the WANT_MONITOR flag. :)

johannes
--


Hmm...

roger@dragon:~/linux-mainline$ find . -name "*.[ch]" -exec grep -n 
IEEE80211_HW_WANT_MONITOR_VIF {} \; -print
1851: * @IEEE80211_HW_WANT_MONITOR_VIF: The driver would like to be 
informed of

1928:IEEE80211_HW_WANT_MONITOR_VIF,
./include/net/mac80211.h

Is that what you meant. Nobody seems to be using it. Even mac80211 
itself. Or am I being stupid again :-)




Roger
--
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] ath10k: Advertise force AP scan feature

[Vasanthakumar Thiagarajan]

Results obtained from scan can be used for spectrum management by
doing something like building information of preferred channel
lists and sharing them with stations around. It is to be noted
that traffic to the connected stations would be affected during
the scan.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index ebff9c0..48b789c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7697,7 +7697,8 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->max_remain_on_channel_duration = 5000;
 
ar->hw->wiphy->flags |= WIPHY_FLAG_AP_UAPSD;
-   ar->hw->wiphy->features |= NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE;
+   ar->hw->wiphy->features |= NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE |
+  NL80211_FEATURE_AP_SCAN;
 
ar->hw->wiphy->max_ap_assoc_sta = ar->max_num_stations;
 
-- 
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 5/7] staging: wilc1000: changes an ambiguous debug messages

[Leo Kim]

This patches changes an ambiguous debug messages.
The device types are both SDIO or SPI.

Signed-off-by: Leo Kim 
---
 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 1a5de2e..e949f21 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -907,7 +907,7 @@ int wilc_mac_open(struct net_device *ndev)
wl = vif->wilc;
 
if (!wl || !wl->dev) {
-   netdev_err(ndev, "wilc1000: SPI device not ready\n");
+   netdev_err(ndev, "device not ready\n");
return -ENODEV;
}
 
-- 
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 2/7] staging: wilc1000: wilc_spi.c: removes debug print log

[Leo Kim]

This patches removes unnecessary debug print logs.

Signed-off-by: Leo Kim 
---
 drivers/staging/wilc1000/wilc_spi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index d41b8b6..4268e2f 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -196,9 +196,6 @@ static int wilc_spi_tx(struct wilc *wilc, u8 *b, u32 len)
dev_err(>dev,
"can't write data with the following length: %d\n",
len);
-   dev_err(>dev,
-   "FAILED due to NULL buffer or ZERO length check the 
following length: %d\n",
-   len);
ret = -EINVAL;
}
 
-- 
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 3/7] staging: wilc1000: removes duplicate vif variable setting

[Leo Kim]

This patches removes duplicate vif variable setting.
This value has already been set previously.

Signed-off-by: Leo Kim 
---
 drivers/staging/wilc1000/linux_wlan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index bfa754b..8a10831 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -912,7 +912,6 @@ int wilc_mac_open(struct net_device *ndev)
return -ENODEV;
}
 
-   vif = netdev_priv(ndev);
wilc = vif->wilc;
priv = wiphy_priv(vif->ndev->ieee80211_ptr->wiphy);
netdev_dbg(ndev, "MAC OPEN[%p]\n", ndev);
-- 
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: pull-request: wireless-drivers-next 2016-03-14

[Kalle Valo]

David Miller  writes:

> From: Kalle Valo 
> Date: Mon, 14 Mar 2016 10:31:48 +0200
>
>> I know I'm late now that merge window was opened yesterday but here's
>> one more set of patches I would like to get to 4.6 still. There isn't
>> anything controversial so I hope this should be still safe to pull. The
>> patches have been in linux-next since Friday and I haven't seen any
>> reports about issues. But if you think it's too late just let me know
>> and I'll resubmit these for 4.7.
>> 
>> The most notable part here of course is rtl8xxxu with over 100 patches.
>> As the driver is new and under heavy development I think they are ok to
>> take still. Otherwise there are mostly fixes with an exception of adding
>> a new debugfs file to wl18xx.
>> 
>> Please let me know if you have any problems.
>
> Pulled, thanks.

Great, thanks a lot.

> I really like Jes's work and I wish you had integrated it several
> months ago, instead of sloshing him needlessly through a non-stop
> cycle of very nit-picky issues, just FYI.

I also like his work and I'm sorry for being too nit-picky. I have tried
to be extra careful with the patches I send to you, especially with new
drivers, and I guess I have been too pedantic. I'll try to lower the bar
to a more reasonable level.

But I actually started to wonder what you actually mean and checked the
dates of initial rtl8xxxu submission from patchwork:

2015-08-29 v1
2015-08-30 v2
2015-10-15 v3
2015-10-21 applied 26f1fad29ad9 to w-d-next for v4.4

Two months is quite long for a good driver like this but IIRC the
initial commit was pending wireless-drivers directory reorganisation,
and that just took too long on my side.

-- 
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

[patch] brcmfmac: uninitialized "ret" variable

[Dan Carpenter]

There is an error path where "ret" isn't initialized.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index da0cdd3..2fc0597 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -250,7 +250,7 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev 
*sdiodev, u8 fn,
u32 addr, u8 regsz, void *data, bool write)
 {
struct sdio_func *func;
-   int ret;
+   int ret = -EINVAL;
 
brcmf_dbg(SDIO, "rw=%d, func=%d, addr=0x%05x, nbytes=%d\n",
  write, fn, addr, regsz);
--
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