Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: [RESEND, PATCH v3 3/3] mwifiex: debugfs: trigger device dump for usb interface
From: Kalle Valo @ 2017-12-04  9:46 UTC (permalink / raw)
  To: Xinming Hu
  Cc: Linux Wireless, Brian Norris, Dmitry Torokhov, rajatja,
	Zhiyuan Yang, Tim Song, Cathy Luo, James Cao, Ganapathi Bhat,
	Ellie Reeves
In-Reply-To: <1512370563-24660-1-git-send-email-huxm@marvell.com>

Xinming Hu <huxm@marvell.com> writes:

> This patch extend device_dump debugfs function to make it
> works for usb interface.
>
> For command timeouts, USB firmware will automatically emit
> firmware dump events, so we don't implement device_dump().
>
> For user-initiated dumps, we trigger it by issue firmware
> dump event command to firmware, as there is no command
> response, do not start 10s timer.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> ---
> v2: Same as v1
> v3: Add more comments Regards the different dump mechanism
>     between usb and other interfaces.(Brian Norris)

Please always resubmit the whole patchset, not individual patches:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#resubmit_the_whole_patchset

Also please don't use that awkward "RESEND" stuff some people seem to
insist using. So instead of doing like this:

v2, v3, v3 RESEND, v4

do it like this which makes my life easier:

v2, v3, v4, v5

It's not like we are running out of version numbers :)

-- 
Kalle Valo

^ permalink raw reply

* Re: Make SSB a menuconfig to ease disabling it all
From: Kalle Valo @ 2017-12-04 10:01 UTC (permalink / raw)
  To: Vincent Legoll; +Cc: m, linux-wireless, linux-kernel
In-Reply-To: <20171203211921.20233-1-vincent.legoll@gmail.com>

Vincent Legoll <vincent.legoll@gmail.com> writes:

> The following patch makes it easier to disable all SSB config
> options without entering the submenu. It will also enable one
> to see that en-disabled state from the outside menu.
>
> This is only intended to change menuconfig UI, not change
> the config dependencies.

So you have just oneliners as the commit log in the patch and here in
the cover letter you have a better description. As the cover letters are
not normally archived to the git repository it's better to have the
proper log in the commit log.

Also prefix the title with "ssb: " like other patches have done:

$ git log --oneline -10 drivers/ssb/
b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files with no license
c6c092dcb21e ssb: Delete an error message for a failed memory allocation in ssb_devices_register()
8052d7245b60 ssb: Fix error routine when fallback SPROM fails
c683ffe2193b SSB: Change bare unsigned to unsigned int to suit coding style
2d4443be10a7 ssb: gpio_driver: use gpiochip data pointer
10da848f67a7 ssb: host_soc depends on sprom
b7e2d195cc52 ssb: mark ssb_bus_register as __maybe_unused
541c9a84cd85 ssb: pick SoC invariants code from MIPS BCM47xx arch
845da6e58e19 ssb: add Kconfig entry for compiling SoC related code
830c7df46247 ssb: move functions specific to SoC hosted bus to separated file

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH 2/2] ath10k: add per peer tx stats support for 10.2.4
From: akolli @ 2017-12-04 11:20 UTC (permalink / raw)
  To: Kalle Valo
  Cc: mbizon, linux-wireless-owner, Anilkumar Kolli, linux-wireless,
	ath10k
In-Reply-To: <87374uxxjy.fsf@kamboji.qca.qualcomm.com>


> 
>>>> Parse peer stats from pktlog packets and update the tx rate
>>>> information
>>>> per STA. This way user space can query about transmit rate with iw:
>>> 
>>> everything works ok, ath10k_update_per_peer_tx_stats() is called and
>>> ath10k_sta fields are updated correctly
>>> 
>>> but tx bitrate is still 6 MBit/s in station dump
>>> 
>> Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
>> Please Run ping traffic and see and 'station dump'
> 
> This feature should not depend on debugfs. Why is it needed? In patch 1
> you already moved pktlog_filter to struct ath10k, does it need 
> something
> else as well?

ATH10K updates tx rate from this callback,
.sta_statistics                 = ath10k_sta_statistics,

This callback is defined under CONFIG_MAC80211_DEBUGFS.

Thanks,
Anil.

^ permalink raw reply

* Re: [linuxwifi] Need support for Intel new wifi module 9462NGW
From: Luca Coelho @ 2017-12-04 11:43 UTC (permalink / raw)
  To: Chris Chiu
  Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <CAB4CAwd68miZHrVxhx2nGey-6685+19d4wXvhCux1KER+j1KNQ@mail.gmail.com>

On Mon, 2017-12-04 at 13:36 +0800, Chris Chiu wrote:
> Hi Luca,
>     I applied https://patchwork.kernel.org/patch/10088929/ and
> https://patchwork.kernel.org/patch/10088939/, I can access internet
> thru 9461/9462NGW now. Thanks so much.

Thanks for testing!

Great that it works now.  I'll queue this patches for stable.

--
Cheers,
Luca.

^ permalink raw reply

* [PATCH v4 1/3] mwifiex: refactor device dump code to make it generic for usb interface
From: Xinming Hu @ 2017-12-04 12:18 UTC (permalink / raw)
  To: Linux Wireless
  Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, rajatja, Zhiyuan Yang,
	Tim Song, Cathy Luo, James Cao, Ganapathi Bhat, Ellie Reeves,
	Xinming Hu

This patch refactor current device dump code to make it generic
for subsequent implementation on usb interface.

Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
---
v2: Addressed below review comments from Brian Norris
    a) use new API timer_setup/from_timer.
    b) reset devdump_len during initization
v4: Same as v2,v3
---
 drivers/net/wireless/marvell/mwifiex/init.c |  1 +
 drivers/net/wireless/marvell/mwifiex/main.c | 87 +++++++++++++++--------------
 drivers/net/wireless/marvell/mwifiex/main.h | 11 +++-
 drivers/net/wireless/marvell/mwifiex/pcie.c | 13 +++--
 drivers/net/wireless/marvell/mwifiex/sdio.c | 14 +++--
 5 files changed, 72 insertions(+), 54 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index e1aa860..b0d3d68 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -314,6 +314,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter)
 	adapter->iface_limit.p2p_intf = MWIFIEX_MAX_P2P_NUM;
 	adapter->active_scan_triggered = false;
 	timer_setup(&adapter->wakeup_timer, wakeup_timer_fn, 0);
+	adapter->devdump_len = 0;
 }
 
 /*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index a96bd7e..f7d0299 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1051,9 +1051,23 @@ void mwifiex_multi_chan_resync(struct mwifiex_adapter *adapter)
 }
 EXPORT_SYMBOL_GPL(mwifiex_multi_chan_resync);
 
-int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info)
+void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter)
 {
-	void *p;
+	/* Dump all the memory data into single file, a userspace script will
+	 * be used to split all the memory data to multiple files
+	 */
+	mwifiex_dbg(adapter, MSG,
+		    "== mwifiex dump information to /sys/class/devcoredump start\n");
+	dev_coredumpv(adapter->dev, adapter->devdump_data, adapter->devdump_len,
+		      GFP_KERNEL);
+	mwifiex_dbg(adapter, MSG,
+		    "== mwifiex dump information to /sys/class/devcoredump end\n");
+}
+EXPORT_SYMBOL_GPL(mwifiex_upload_device_dump);
+
+void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter)
+{
+	char *p;
 	char drv_version[64];
 	struct usb_card_rec *cardp;
 	struct sdio_mmc_card *sdio_card;
@@ -1061,17 +1075,12 @@ int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info)
 	int i, idx;
 	struct netdev_queue *txq;
 	struct mwifiex_debug_info *debug_info;
-	void *drv_info_dump;
 
 	mwifiex_dbg(adapter, MSG, "===mwifiex driverinfo dump start===\n");
 
-	/* memory allocate here should be free in mwifiex_upload_device_dump*/
-	drv_info_dump = vzalloc(MWIFIEX_DRV_INFO_SIZE_MAX);
-
-	if (!drv_info_dump)
-		return 0;
-
-	p = (char *)(drv_info_dump);
+	p = adapter->devdump_data;
+	strcpy(p, "========Start dump driverinfo========\n");
+	p += strlen("========Start dump driverinfo========\n");
 	p += sprintf(p, "driver_name = " "\"mwifiex\"\n");
 
 	mwifiex_drv_get_driver_version(adapter, drv_version,
@@ -1155,21 +1164,18 @@ int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info)
 		kfree(debug_info);
 	}
 
+	strcpy(p, "\n========End dump========\n");
+	p += strlen("\n========End dump========\n");
 	mwifiex_dbg(adapter, MSG, "===mwifiex driverinfo dump end===\n");
-	*drv_info = drv_info_dump;
-	return p - drv_info_dump;
+	adapter->devdump_len = p - (char *)adapter->devdump_data;
 }
 EXPORT_SYMBOL_GPL(mwifiex_drv_info_dump);
 
-void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
-				int drv_info_size)
+void mwifiex_prepare_fw_dump_info(struct mwifiex_adapter *adapter)
 {
-	u8 idx, *dump_data, *fw_dump_ptr;
-	u32 dump_len;
-
-	dump_len = (strlen("========Start dump driverinfo========\n") +
-		       drv_info_size +
-		       strlen("\n========End dump========\n"));
+	u8 idx;
+	char *fw_dump_ptr;
+	u32 dump_len = 0;
 
 	for (idx = 0; idx < adapter->num_mem_types; idx++) {
 		struct memory_type_mapping *entry =
@@ -1184,24 +1190,24 @@ void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
 		}
 	}
 
-	dump_data = vzalloc(dump_len + 1);
-	if (!dump_data)
-		goto done;
-
-	fw_dump_ptr = dump_data;
+	if (dump_len + 1 + adapter->devdump_len > MWIFIEX_FW_DUMP_SIZE) {
+		/* Realloc in case buffer overflow */
+		fw_dump_ptr = vzalloc(dump_len + 1 + adapter->devdump_len);
+		mwifiex_dbg(adapter, MSG, "Realloc device dump data.\n");
+		if (!fw_dump_ptr) {
+			vfree(adapter->devdump_data);
+			mwifiex_dbg(adapter, ERROR,
+				    "vzalloc devdump data failure!\n");
+			return;
+		}
 
-	/* Dump all the memory data into single file, a userspace script will
-	 * be used to split all the memory data to multiple files
-	 */
-	mwifiex_dbg(adapter, MSG,
-		    "== mwifiex dump information to /sys/class/devcoredump start");
+		memmove(fw_dump_ptr, adapter->devdump_data,
+			adapter->devdump_len);
+		vfree(adapter->devdump_data);
+		adapter->devdump_data = fw_dump_ptr;
+	}
 
-	strcpy(fw_dump_ptr, "========Start dump driverinfo========\n");
-	fw_dump_ptr += strlen("========Start dump driverinfo========\n");
-	memcpy(fw_dump_ptr, drv_info, drv_info_size);
-	fw_dump_ptr += drv_info_size;
-	strcpy(fw_dump_ptr, "\n========End dump========\n");
-	fw_dump_ptr += strlen("\n========End dump========\n");
+	fw_dump_ptr = (char *)adapter->devdump_data + adapter->devdump_len;
 
 	for (idx = 0; idx < adapter->num_mem_types; idx++) {
 		struct memory_type_mapping *entry =
@@ -1228,11 +1234,8 @@ void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
 	/* device dump data will be free in device coredump release function
 	 * after 5 min
 	 */
-	dev_coredumpv(adapter->dev, dump_data, dump_len, GFP_KERNEL);
-	mwifiex_dbg(adapter, MSG,
-		    "== mwifiex dump information to /sys/class/devcoredump end");
+	adapter->devdump_len = fw_dump_ptr - (char *)adapter->devdump_data;
 
-done:
 	for (idx = 0; idx < adapter->num_mem_types; idx++) {
 		struct memory_type_mapping *entry =
 			&adapter->mem_type_mapping_tbl[idx];
@@ -1241,10 +1244,8 @@ void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
 		entry->mem_ptr = NULL;
 		entry->mem_size = 0;
 	}
-
-	vfree(drv_info);
 }
-EXPORT_SYMBOL_GPL(mwifiex_upload_device_dump);
+EXPORT_SYMBOL_GPL(mwifiex_prepare_fw_dump_info);
 
 /*
  * CFG802.11 network device handler for statistics retrieval.
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 154c079..8b6241a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -94,6 +94,8 @@ enum {
 
 #define MAX_EVENT_SIZE                  2048
 
+#define MWIFIEX_FW_DUMP_SIZE       (2 * 1024 * 1024)
+
 #define ARP_FILTER_MAX_BUF_SIZE         68
 
 #define MWIFIEX_KEY_BUFFER_SIZE			16
@@ -1032,6 +1034,9 @@ struct mwifiex_adapter {
 	bool wake_by_wifi;
 	/* Aggregation parameters*/
 	struct bus_aggr_params bus_aggr;
+	/* Device dump data/length */
+	void *devdump_data;
+	int devdump_len;
 };
 
 void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
@@ -1656,9 +1661,9 @@ void mwifiex_hist_data_add(struct mwifiex_private *priv,
 u8 mwifiex_adjust_data_rate(struct mwifiex_private *priv,
 			    u8 rx_rate, u8 ht_info);
 
-int mwifiex_drv_info_dump(struct mwifiex_adapter *adapter, void **drv_info);
-void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter, void *drv_info,
-				int drv_info_size);
+void mwifiex_drv_info_dump(struct mwifiex_adapter *adapter);
+void mwifiex_prepare_fw_dump_info(struct mwifiex_adapter *adapter);
+void mwifiex_upload_device_dump(struct mwifiex_adapter *adapter);
 void *mwifiex_alloc_dma_align_buf(int rx_len, gfp_t flags);
 void mwifiex_queue_main_work(struct mwifiex_adapter *adapter);
 int mwifiex_get_wakeup_reason(struct mwifiex_private *priv, u16 action,
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index cd31494..f666cb2 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2769,12 +2769,17 @@ static void mwifiex_pcie_fw_dump(struct mwifiex_adapter *adapter)
 
 static void mwifiex_pcie_device_dump_work(struct mwifiex_adapter *adapter)
 {
-	int drv_info_size;
-	void *drv_info;
+	adapter->devdump_data = vzalloc(MWIFIEX_FW_DUMP_SIZE);
+	if (!adapter->devdump_data) {
+		mwifiex_dbg(adapter, ERROR,
+			    "vzalloc devdump data failure!\n");
+		return;
+	}
 
-	drv_info_size = mwifiex_drv_info_dump(adapter, &drv_info);
+	mwifiex_drv_info_dump(adapter);
 	mwifiex_pcie_fw_dump(adapter);
-	mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
+	mwifiex_prepare_fw_dump_info(adapter);
+	mwifiex_upload_device_dump(adapter);
 }
 
 static void mwifiex_pcie_card_reset_work(struct mwifiex_adapter *adapter)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index fd5183c..a828801 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2505,15 +2505,21 @@ static void mwifiex_sdio_generic_fw_dump(struct mwifiex_adapter *adapter)
 static void mwifiex_sdio_device_dump_work(struct mwifiex_adapter *adapter)
 {
 	struct sdio_mmc_card *card = adapter->card;
-	int drv_info_size;
-	void *drv_info;
 
-	drv_info_size = mwifiex_drv_info_dump(adapter, &drv_info);
+	adapter->devdump_data = vzalloc(MWIFIEX_FW_DUMP_SIZE);
+	if (!adapter->devdump_data) {
+		mwifiex_dbg(adapter, ERROR,
+			    "vzalloc devdump data failure!\n");
+		return;
+	}
+
+	mwifiex_drv_info_dump(adapter);
 	if (card->fw_dump_enh)
 		mwifiex_sdio_generic_fw_dump(adapter);
 	else
 		mwifiex_sdio_fw_dump(adapter);
-	mwifiex_upload_device_dump(adapter, drv_info, drv_info_size);
+	mwifiex_prepare_fw_dump_info(adapter);
+	mwifiex_upload_device_dump(adapter);
 }
 
 static void mwifiex_sdio_work(struct work_struct *work)
-- 
1.9.1

^ permalink raw reply related

* [PATCH v4 2/3] mwifiex: device dump support for usb interface
From: Xinming Hu @ 2017-12-04 12:18 UTC (permalink / raw)
  To: Linux Wireless
  Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, rajatja, Zhiyuan Yang,
	Tim Song, Cathy Luo, James Cao, Ganapathi Bhat, Ellie Reeves,
	Xinming Hu
In-Reply-To: <1512389924-25674-1-git-send-email-huxm@marvell.com>

Firmware dump on usb interface is different with current
sdio/pcie chipset, which is based on register operation.

When firmware hang on usb interface, context dump will be
upload to host using 0x73 firmware debug event.

This patch store dump data from debug event and send to
userspace using device coredump API.

Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
---
v2: Addressed below review comments from Brian Norris
    a) Check for overflow introduced by invalid event.
    b) Use end of transmission signal to recognize last event.
v4: Same as v2,v3
---
 drivers/net/wireless/marvell/mwifiex/fw.h        | 10 ++++
 drivers/net/wireless/marvell/mwifiex/init.c      |  9 ++++
 drivers/net/wireless/marvell/mwifiex/main.h      |  2 +
 drivers/net/wireless/marvell/mwifiex/sta_event.c | 61 ++++++++++++++++++++++++
 4 files changed, 82 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 13cd58e9..4d5e686 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -56,6 +56,15 @@ struct mwifiex_fw_data {
 	u8 data[1];
 } __packed;
 
+struct mwifiex_fw_dump_header {
+	__le16          seq_num;
+	__le16          reserved;
+	__le16          type;
+	__le16          len;
+} __packed;
+
+#define FW_DUMP_INFO_ENDED 0x0002
+
 #define MWIFIEX_FW_DNLD_CMD_1 0x1
 #define MWIFIEX_FW_DNLD_CMD_5 0x5
 #define MWIFIEX_FW_DNLD_CMD_6 0x6
@@ -570,6 +579,7 @@ enum mwifiex_channel_flags {
 #define EVENT_BG_SCAN_STOPPED           0x00000065
 #define EVENT_REMAIN_ON_CHAN_EXPIRED    0x0000005f
 #define EVENT_MULTI_CHAN_INFO           0x0000006a
+#define EVENT_FW_DUMP_INFO		0x00000073
 #define EVENT_TX_STATUS_REPORT		0x00000074
 #define EVENT_BT_COEX_WLAN_PARA_CHANGE	0X00000076
 
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index b0d3d68..d239e92 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -64,6 +64,13 @@ static void wakeup_timer_fn(struct timer_list *t)
 		adapter->if_ops.card_reset(adapter);
 }
 
+static void fw_dump_timer_fn(struct timer_list *t)
+{
+	struct mwifiex_adapter *adapter = from_timer(adapter, t, devdump_timer);
+
+	mwifiex_upload_device_dump(adapter);
+}
+
 /*
  * This function initializes the private structure and sets default
  * values to the members.
@@ -315,6 +322,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter)
 	adapter->active_scan_triggered = false;
 	timer_setup(&adapter->wakeup_timer, wakeup_timer_fn, 0);
 	adapter->devdump_len = 0;
+	timer_setup(&adapter->devdump_timer, fw_dump_timer_fn, 0);
 }
 
 /*
@@ -397,6 +405,7 @@ static void mwifiex_invalidate_lists(struct mwifiex_adapter *adapter)
 mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
 {
 	del_timer(&adapter->wakeup_timer);
+	del_timer_sync(&adapter->devdump_timer);
 	mwifiex_cancel_all_pending_cmd(adapter);
 	wake_up_interruptible(&adapter->cmd_wait_q.wait);
 	wake_up_interruptible(&adapter->hs_activate_wait_q);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 8b6241a..6b5539b 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1037,6 +1037,7 @@ struct mwifiex_adapter {
 	/* Device dump data/length */
 	void *devdump_data;
 	int devdump_len;
+	struct timer_list devdump_timer;
 };
 
 void mwifiex_process_tx_queue(struct mwifiex_adapter *adapter);
@@ -1682,6 +1683,7 @@ void mwifiex_process_multi_chan_event(struct mwifiex_private *priv,
 void mwifiex_multi_chan_resync(struct mwifiex_adapter *adapter);
 int mwifiex_set_mac_address(struct mwifiex_private *priv,
 			    struct net_device *dev);
+void mwifiex_devdump_tmo_func(unsigned long function_context);
 
 #ifdef CONFIG_DEBUG_FS
 void mwifiex_debugfs_init(void);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index d8db412..93dfb76 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -584,6 +584,62 @@ void mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
 		adapter->coex_rx_win_size);
 }
 
+static void
+mwifiex_fw_dump_info_event(struct mwifiex_private *priv,
+			   struct sk_buff *event_skb)
+{
+	struct mwifiex_adapter *adapter = priv->adapter;
+	struct mwifiex_fw_dump_header *fw_dump_hdr =
+				(void *)adapter->event_body;
+
+	if (adapter->iface_type != MWIFIEX_USB) {
+		mwifiex_dbg(adapter, MSG,
+			    "event is not on usb interface, ignore it\n");
+		return;
+	}
+
+	if (!adapter->devdump_data) {
+		/* When receive the first event, allocate device dump
+		 * buffer, dump driver info.
+		 */
+		adapter->devdump_data = vzalloc(MWIFIEX_FW_DUMP_SIZE);
+		if (!adapter->devdump_data) {
+			mwifiex_dbg(adapter, ERROR,
+				    "vzalloc devdump data failure!\n");
+			return;
+		}
+
+		mwifiex_drv_info_dump(adapter);
+
+		/* If no proceeded event arrive in 10s, upload device
+		 * dump data, this will be useful if the end of
+		 * transmission event get lost, in this cornel case,
+		 * user would still get partial of the dump.
+		 */
+		mod_timer(&adapter->devdump_timer,
+			  jiffies + msecs_to_jiffies(MWIFIEX_TIMER_10S));
+	}
+
+	/* Overflow check */
+	if (adapter->devdump_len + event_skb->len >= MWIFIEX_FW_DUMP_SIZE)
+		goto upload_dump;
+
+	memmove(adapter->devdump_data + adapter->devdump_len,
+		adapter->event_skb->data, event_skb->len);
+	adapter->devdump_len += event_skb->len;
+
+	if (le16_to_cpu(fw_dump_hdr->type == FW_DUMP_INFO_ENDED)) {
+		mwifiex_dbg(adapter, MSG,
+			    "receive end of transmission flag event!\n");
+		goto upload_dump;
+	}
+	return;
+
+upload_dump:
+	del_timer_sync(&adapter->devdump_timer);
+	mwifiex_upload_device_dump(adapter);
+}
+
 /*
  * This function handles events generated by firmware.
  *
@@ -636,6 +692,7 @@ void mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
  *      - EVENT_DELBA
  *      - EVENT_BA_STREAM_TIEMOUT
  *      - EVENT_AMSDU_AGGR_CTRL
+ *      - EVENT_FW_DUMP_INFO
  */
 int mwifiex_process_sta_event(struct mwifiex_private *priv)
 {
@@ -1007,6 +1064,10 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
 					    adapter->event_skb->len -
 					    sizeof(eventcause));
 		break;
+	case EVENT_FW_DUMP_INFO:
+		mwifiex_dbg(adapter, EVENT, "event: firmware debug info\n");
+		mwifiex_fw_dump_info_event(priv, adapter->event_skb);
+		break;
 	/* Debugging event; not used, but let's not print an ERROR for it. */
 	case EVENT_UNKNOWN_DEBUG:
 		mwifiex_dbg(adapter, EVENT, "event: debug\n");
-- 
1.9.1

^ permalink raw reply related

* [PATCH v4 3/3] mwifiex: debugfs: trigger device dump for usb interface
From: Xinming Hu @ 2017-12-04 12:18 UTC (permalink / raw)
  To: Linux Wireless
  Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, rajatja, Zhiyuan Yang,
	Tim Song, Cathy Luo, James Cao, Ganapathi Bhat, Ellie Reeves,
	Xinming Hu
In-Reply-To: <1512389924-25674-1-git-send-email-huxm@marvell.com>

This patch extend device_dump debugfs function to make it
works for usb interface.

For command timeouts, USB firmware will automatically emit
firmware dump events, so we don't implement device_dump().

For user-initiated dumps, we trigger it by issue firmware
dump event command to firmware, as there is no command
response, do not start 10s timer.

Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
---
v2: Same as v1
v3: Add more comments Regards the different dump mechanism
    between usb and other interfaces.(Brian Norris)
v4: Same as v3
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c  | 11 +++++++----
 drivers/net/wireless/marvell/mwifiex/debugfs.c | 13 +++++++++----
 drivers/net/wireless/marvell/mwifiex/fw.h      |  1 +
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c |  4 ++++
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index dcc529e..8746600 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -290,13 +290,16 @@ static int mwifiex_dnld_cmd_to_fw(struct mwifiex_private *priv,
 	adapter->dbg.last_cmd_act[adapter->dbg.last_cmd_index] =
 			get_unaligned_le16((u8 *)host_cmd + S_DS_GEN);
 
+	/* Setup the timer after transmit command, except that specific
+	 * command might not have command response.
+	 */
+	if (cmd_code != HostCmd_CMD_FW_DUMP_EVENT)
+		mod_timer(&adapter->cmd_timer,
+			  jiffies + msecs_to_jiffies(MWIFIEX_TIMER_10S));
+
 	/* Clear BSS_NO_BITS from HostCmd */
 	cmd_code &= HostCmd_CMD_ID_MASK;
 
-	/* Setup the timer after transmit command */
-	mod_timer(&adapter->cmd_timer,
-		  jiffies + msecs_to_jiffies(MWIFIEX_TIMER_10S));
-
 	return 0;
 }
 
diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c b/drivers/net/wireless/marvell/mwifiex/debugfs.c
index 6f4239b..db2872d 100644
--- a/drivers/net/wireless/marvell/mwifiex/debugfs.c
+++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c
@@ -168,10 +168,15 @@
 {
 	struct mwifiex_private *priv = file->private_data;
 
-	if (!priv->adapter->if_ops.device_dump)
-		return -EIO;
-
-	priv->adapter->if_ops.device_dump(priv->adapter);
+	/* For command timeouts, USB firmware will automatically emit
+	 * firmware dump events, so we don't implement device_dump().
+	 * For user-initiated dumps, we trigger it ourselves.
+	 */
+	if (priv->adapter->iface_type == MWIFIEX_USB)
+		mwifiex_send_cmd(priv, HostCmd_CMD_FW_DUMP_EVENT,
+				 HostCmd_ACT_GEN_SET, 0, NULL, true);
+	else
+		priv->adapter->if_ops.device_dump(priv->adapter);
 
 	return 0;
 }
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 4d5e686..9c2cdef 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -409,6 +409,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
 #define HostCmd_CMD_TDLS_CONFIG                       0x0100
 #define HostCmd_CMD_MC_POLICY                         0x0121
 #define HostCmd_CMD_TDLS_OPER                         0x0122
+#define HostCmd_CMD_FW_DUMP_EVENT		      0x0125
 #define HostCmd_CMD_SDIO_SP_RX_AGGR_CFG               0x0223
 #define HostCmd_CMD_CHAN_REGION_CFG		      0x0242
 #define HostCmd_CMD_PACKET_AGGR_CTRL		      0x0251
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index fb09014..211e47d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2206,6 +2206,10 @@ int mwifiex_sta_prepare_cmd(struct mwifiex_private *priv, uint16_t cmd_no,
 	case HostCmd_CMD_CHAN_REGION_CFG:
 		ret = mwifiex_cmd_chan_region_cfg(priv, cmd_ptr, cmd_action);
 		break;
+	case HostCmd_CMD_FW_DUMP_EVENT:
+		cmd_ptr->command = cpu_to_le16(cmd_no);
+		cmd_ptr->size = cpu_to_le16(S_DS_GEN);
+		break;
 	default:
 		mwifiex_dbg(priv->adapter, ERROR,
 			    "PREP_CMD: unknown cmd- %#x\n", cmd_no);
-- 
1.9.1

^ permalink raw reply related

* Re: [PATCH 12/15] iwlwifi: mvm: enable RX offloading with TKIP and WEP
From: Luciano Coelho @ 2017-12-04 12:57 UTC (permalink / raw)
  To: kvalo; +Cc: linux-wireless, David Spinadel
In-Reply-To: <20171202162858.4167-13-luca@coelho.fi>

On Sat, 2017-12-02 at 18:28 +0200, Luca Coelho wrote:
> From: David Spinadel <david.spinadel@intel.com>
> 
> Set the flag that indicates that ICV was stripped on if
> this option was enabled in the HW.
> 
> Signed-off-by: David Spinadel <david.spinadel@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---

I'll move this to my fixes series, because it's needed for the 9000
series, which is currently broken upstream... :(

--
Cheers,
Luca.

^ permalink raw reply

* Re: [PATCH 13/15] iwlwifi: mvm: mark MIC stripped MPDUs
From: Luciano Coelho @ 2017-12-04 12:57 UTC (permalink / raw)
  To: kvalo; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <20171202162858.4167-14-luca@coelho.fi>

On Sat, 2017-12-02 at 18:28 +0200, Luca Coelho wrote:
> From: Sara Sharon <sara.sharon@intel.com>
> 
> When RADA is active, the hardware decrypts the packets and strips off
> the MIC as it is useless after decryption. Indicate that to mac80211.
> 
> Signed-off-by: Sara Sharon <sara.sharon@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
>  drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
> index 0e6a7dd30aa9..a81ff4163d05 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
> @@ -253,6 +253,8 @@ static int iwl_mvm_rx_crypto(struct iwl_mvm *mvm,
> struct ieee80211_hdr *hdr,
>  			return -1;
>  
>  		stats->flag |= RX_FLAG_DECRYPTED;
> +		if (pkt_flags & FH_RSCSR_RADA_EN)
> +			stats->flag |= RX_FLAG_MIC_STRIPPED;
>  		*crypt_len = IEEE80211_CCMP_HDR_LEN;
>  		return 0;
>  	case IWL_RX_MPDU_STATUS_SEC_TKIP:

Same thing here, I'll move it to the -fixes series, since it's needed
by 9000-series NICs.

--
Cheers,
Luca.

^ permalink raw reply

* Re: [PATCH 2/2] ath10k: add per peer tx stats support for 10.2.4
From: akolli @ 2017-12-04 13:24 UTC (permalink / raw)
  To: mbizon; +Cc: akolli, ath10k, linux-wireless, linux-wireless-owner
In-Reply-To: <1512140710.38490.81.camel@sakura.staff.proxad.net>

On 2017-12-01 20:35, Maxime Bizon wrote:
> On Fri, 2017-12-01 at 19:18 +0530, akolli@codeaurora.org wrote:
> 
>> Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
> 
> it wasn't and IMHO it's confusing because tx rate is filled by the 
> other
> drivers without it.
> 
> I now have the following warning:
> 
> [   96.174967] ------------[ cut here ]------------
> [   96.179640] WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254
> cfg80211_calculate_bitrate+0x174/0x220
> [   96.189538] invalid rate bw=1, mcs=9, nss=2
> [   96.219736] CPU: 0 PID: 609 Comm: hostapd Not tainted
> 4.14.3-00381-gec9756b0f64d #28
> [   96.227910] Hardware name: Marvell Kirkwood (Flattened Device Tree)
> [   96.235450] [<80010124>] (unwind_backtrace) from [<8000d9ec>]
> (show_stack+0x10/0x14)
> [   96.247180] [<8000d9ec>] (show_stack) from [<8002016c>] 
> (__warn+0xdc/0xf8)
> [   96.254243] [<8002016c>] (__warn) from [<800201bc>]
> (warn_slowpath_fmt+0x34/0x44)
> [   96.262016] [<800201bc>] (warn_slowpath_fmt) from [<8064dfdc>]
> (cfg80211_calculate_bitrate+0x174/0x220)
> [   96.272652] [<8064dfdc>] (cfg80211_calculate_bitrate) from
> [<806692d4>] (nl80211_put_sta_rate+0x44/0x1dc)
> [   96.282509] [<806692d4>] (nl80211_put_sta_rate) from [<8066001c>]
> (nl80211_send_station+0x388/0xaf0)
> [   96.292261] [<8066001c>] (nl80211_send_station) from [<8066082c>]
> (nl80211_get_station+0xa8/0xec)
> [   96.304166] [<8066082c>] (nl80211_get_station) from [<80509c20>]
> (genl_rcv_msg+0x2dc/0x34c)
> [   96.313324] [<80509c20>] (genl_rcv_msg) from [<8050890c>]
> (netlink_rcv_skb+0x84/0xdc)
> [   96.321880] [<8050890c>] (netlink_rcv_skb) from [<805093c0>]
> (genl_rcv+0x20/0x34)
> [   96.329668] [<805093c0>] (genl_rcv) from [<80508188>]
> (netlink_unicast+0x12c/0x1e0)
> [   96.338408] [<80508188>] (netlink_unicast) from [<805085d8>]
> (netlink_sendmsg+0x2e0/0x304)
> [   96.350736] [<805085d8>] (netlink_sendmsg) from [<804b5f9c>]
> (sock_sendmsg+0x14/0x24)
> [   96.358656] [<804b5f9c>] (sock_sendmsg) from [<804b66e8>]
> (___sys_sendmsg+0x1c8/0x20c)
> [   96.367093] [<804b66e8>] (___sys_sendmsg) from [<804b739c>]
> (__sys_sendmsg+0x40/0x64)
> [   96.375276] [<804b739c>] (__sys_sendmsg) from [<8000a3e0>]
> (ret_fast_syscall+0x0/0x44)
> [   96.383455] ---[ end trace da8257d6a850e91a ]---
> 
> # iw dev wlan1 station dump
> Station e4:42:a6:24:c8:95 (on wlan1)
> 	inactive time:	550 ms
> 	rx bytes:	41217
> 	rx packets:	152
> 	tx bytes:	49397
> 	tx packets:	107
> 	tx retries:	0
> 	tx failed:	1
> 	rx drop misc:	0
> 	signal:  	-62 [-66, -65, -83] dBm
> 	signal avg:	-61 [-65, -65, -78] dBm
> 	tx bitrate:	 VHT-MCS 9 short GI VHT-NSS 2
> 	rx bitrate:	360.0 MBit/s VHT-MCS 8 40MHz short GI VHT-NSS 2
> 	rx duration:	0 us
> 	authorized:	yes
> 	authenticated:	yes
> 	associated:	yes
> 	preamble:	long
> 	WMM/WME:	yes
> 	MFP:		no
> 	TDLS peer:	no
> 	DTIM period:	2
> 	beacon interval:96
> 	short slot time:yes
> 	connected time:	5 seconds
> 
> Thanks

Hope 10.2.4-1.0-00029 Firmware binary works for you.
I will check this warning.

Thanks,
Anil.

^ permalink raw reply

* Re: [PATCH] staging: wilc1000: Fix problems reported by checkpatch
From: Claudiu Beznea @ 2017-12-04 14:14 UTC (permalink / raw)
  To: Aditya Shankar, linux-wireless; +Cc: ganesh.krishna, gregkh, devel
In-Reply-To: <1512160034-6400-1-git-send-email-aditya.shankar@microchip.com>

Hi Aditya,

On 01.12.2017 22:27, Aditya Shankar wrote:
> This commit fixes below style problems in multiple lines
> Fix checkpatch WARNING: line over 80 characters
> Fix CHECK: Lines should not end with a '('
You should fix only one issue per patch. Would be better to have
a patch with "line over 80 characters fixes" and one with 
"Lines should not end with a '('" fixes. Please see [1].

Thanks,
Claudiu

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#split-changes

> 
> Signed-off-by: Aditya Shankar <aditya.shankar@microchip.com>
> ---
>  drivers/staging/wilc1000/linux_mon.c | 30 ++++++++++++++++++------------
>  1 file changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/linux_mon.c b/drivers/staging/wilc1000/linux_mon.c
> index 91d49c4..a793c42 100644
> --- a/drivers/staging/wilc1000/linux_mon.c
> +++ b/drivers/staging/wilc1000/linux_mon.c
> @@ -69,7 +69,8 @@ void WILC_WFI_monitor_rx(u8 *buff, u32 size)
>  	if (pkt_offset & IS_MANAGMEMENT_CALLBACK) {
>  		/* hostapd callback mgmt frame */
>  
> -		skb = dev_alloc_skb(size + sizeof(struct wilc_wfi_radiotap_cb_hdr));
> +		skb = dev_alloc_skb(size +
> +				    sizeof(struct wilc_wfi_radiotap_cb_hdr));
>  		if (!skb)
>  			return;
>  
> @@ -80,11 +81,12 @@ void WILC_WFI_monitor_rx(u8 *buff, u32 size)
>  
>  		cb_hdr->hdr.it_version = 0; /* PKTHDR_RADIOTAP_VERSION; */
>  
> -		cb_hdr->hdr.it_len = cpu_to_le16(sizeof(struct wilc_wfi_radiotap_cb_hdr));
> +		cb_hdr->hdr.it_len =
> +			cpu_to_le16(sizeof(struct wilc_wfi_radiotap_cb_hdr));
>  
> -		cb_hdr->hdr.it_present = cpu_to_le32(
> -				(1 << IEEE80211_RADIOTAP_RATE) |
> -				(1 << IEEE80211_RADIOTAP_TX_FLAGS));
> +		cb_hdr->hdr.it_present =
> +			cpu_to_le32((1 << IEEE80211_RADIOTAP_RATE) |
> +				    (1 << IEEE80211_RADIOTAP_TX_FLAGS));
>  
>  		cb_hdr->rate = 5; /* txrate->bitrate / 5; */
>  
> @@ -96,7 +98,8 @@ void WILC_WFI_monitor_rx(u8 *buff, u32 size)
>  		}
>  
>  	} else {
> -		skb = dev_alloc_skb(size + sizeof(struct wilc_wfi_radiotap_hdr));
> +		skb = dev_alloc_skb(size +
> +				    sizeof(struct wilc_wfi_radiotap_hdr));
>  
>  		if (!skb)
>  			return;
> @@ -105,7 +108,8 @@ void WILC_WFI_monitor_rx(u8 *buff, u32 size)
>  		hdr = skb_push(skb, sizeof(*hdr));
>  		memset(hdr, 0, sizeof(struct wilc_wfi_radiotap_hdr));
>  		hdr->hdr.it_version = 0; /* PKTHDR_RADIOTAP_VERSION; */
> -		hdr->hdr.it_len = cpu_to_le16(sizeof(struct wilc_wfi_radiotap_hdr));
> +		hdr->hdr.it_len =
> +			cpu_to_le16(sizeof(struct wilc_wfi_radiotap_hdr));
>  		hdr->hdr.it_present = cpu_to_le32
>  				(1 << IEEE80211_RADIOTAP_RATE); /* | */
>  		hdr->rate = 5; /* txrate->bitrate / 5; */
> @@ -197,7 +201,8 @@ static netdev_tx_t WILC_WFI_mon_xmit(struct sk_buff *skb,
>  	skb_pull(skb, rtap_len);
>  
>  	if (skb->data[0] == 0xc0 && (!(memcmp(broadcast, &skb->data[4], 6)))) {
> -		skb2 = dev_alloc_skb(skb->len + sizeof(struct wilc_wfi_radiotap_cb_hdr));
> +		skb2 = dev_alloc_skb(skb->len +
> +				     sizeof(struct wilc_wfi_radiotap_cb_hdr));
>  		if (!skb2)
>  			return -ENOMEM;
>  
> @@ -208,11 +213,12 @@ static netdev_tx_t WILC_WFI_mon_xmit(struct sk_buff *skb,
>  
>  		cb_hdr->hdr.it_version = 0; /* PKTHDR_RADIOTAP_VERSION; */
>  
> -		cb_hdr->hdr.it_len = cpu_to_le16(sizeof(struct wilc_wfi_radiotap_cb_hdr));
> +		cb_hdr->hdr.it_len =
> +			cpu_to_le16(sizeof(struct wilc_wfi_radiotap_cb_hdr));
>  
> -		cb_hdr->hdr.it_present = cpu_to_le32(
> -				(1 << IEEE80211_RADIOTAP_RATE) |
> -				(1 << IEEE80211_RADIOTAP_TX_FLAGS));
> +		cb_hdr->hdr.it_present =
> +			cpu_to_le32((1 << IEEE80211_RADIOTAP_RATE) |
> +				    (1 << IEEE80211_RADIOTAP_TX_FLAGS));
>  
>  		cb_hdr->rate = 5; /* txrate->bitrate / 5; */
>  		cb_hdr->tx_flags = 0x0004;
> 

^ permalink raw reply

* Re: [PATCH 2/2] ath10k: add per peer tx stats support for 10.2.4
From: Maxime Bizon @ 2017-12-04 14:23 UTC (permalink / raw)
  To: akolli; +Cc: akolli, ath10k, linux-wireless, linux-wireless-owner
In-Reply-To: <45d5ada8ea658e49af85582b4f3f71f7@codeaurora.org>


On Mon, 2017-12-04 at 18:54 +0530, akolli@codeaurora.org wrote:

> Hope 10.2.4-1.0-00029 Firmware binary works for you.

it does

> I will check this warning.

fixed by applying patch:
 "[PATCH] ath10k: fix recent bandwidth conversion bug"

as suggested by Christian Lamparter

only remaining oddity is the CONFIG_MAC80211_DEBUGFS dependency

-- 
Maxime

^ permalink raw reply

* Re: [PATCH 02/10] qtnfmac: pass complete channel data between driver and firmware
From: Kalle Valo @ 2017-12-04 14:46 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
In-Reply-To: <20171113102815.11254-3-sergey.matyukevich.os@quantenna.com>

Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:

> Center frequency is not enough to describe the channel in HT and VHT
> modes. For 40MHz and 80MHz channels both primary channel and center
> frequency should be specified in order to qualify channel completely.
> This change adds primary channel info into qlink_chandef structure.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>

[...]

> +/**
>   * struct qlink_chandef - qlink channel definition
>   *
> + * @chan: primary channel definition
>   * @center_freq1: center frequency of first segment
>   * @center_freq2: center frequency of second segment (80+80 only)
>   * @width: channel width, one of @enum qlink_channel_width
>   */
>  struct qlink_chandef {
> +	struct qlink_channel chan;
>  	__le16 center_freq1;
>  	__le16 center_freq2;
>  	u8 width;
> -	u8 rsvd[3];
> +	u8 rsvd;
>  } __packed;

Doesn't this break backwards compatibility with the older firmware? The
basic princinple is that old firmware images continue to work with newer
driver (or there will be a firmware image with new name, eg. fw-2.bin).
You can check how iwlwifi does that.

As this is a new driver I guess it doesn't matter that much to break it,
but please keep this in mind in the future.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH 03/10] qtnfmac: add support for radar detection and CAC
From: Kalle Valo @ 2017-12-04 14:49 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
In-Reply-To: <20171113102815.11254-4-sergey.matyukevich.os@quantenna.com>

Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:

> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> Implement two parts of radar handling logic:
> - cfg80211 .start_radar_detect callback to allow nl80211 to initiate CAC
> - radar event to allow wlan device to advertize CAC and radar events
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>

[...]

> +int qtnf_cmd_start_cac(const struct qtnf_vif *vif,
> +		       const struct cfg80211_chan_def *chdef,
> +		       u32 cac_time_ms)
> +{
> +	struct qtnf_bus *bus = vif->mac->bus;
> +	struct sk_buff *cmd_skb;
> +	struct qlink_cmd_start_cac *cmd;
> +	int ret;
> +	u16 res_code;
> +
> +	cmd_skb = qtnf_cmd_alloc_new_cmdskb(vif->mac->macid, vif->vifid,
> +					    QLINK_CMD_START_CAC,
> +					    sizeof(*cmd));
> +	if (unlikely(!cmd_skb))
> +		return -ENOMEM;

The unlikely() looks pretty useless here. likely() and unlikely() are
supposed to be used in cases where it matters and the improvment can be
measured, I doubt that's the case here.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH 03/10] qtnfmac: add support for radar detection and CAC
From: Kalle Valo @ 2017-12-04 14:52 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
In-Reply-To: <87a7yylf9e.fsf@purkki.adurom.net>

Kalle Valo <kvalo@codeaurora.org> writes:

> Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:
>
>> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>>
>> Implement two parts of radar handling logic:
>> - cfg80211 .start_radar_detect callback to allow nl80211 to initiate CAC
>> - radar event to allow wlan device to advertize CAC and radar events
>>
>> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> [...]
>
>> +int qtnf_cmd_start_cac(const struct qtnf_vif *vif,
>> +		       const struct cfg80211_chan_def *chdef,
>> +		       u32 cac_time_ms)
>> +{
>> +	struct qtnf_bus *bus = vif->mac->bus;
>> +	struct sk_buff *cmd_skb;
>> +	struct qlink_cmd_start_cac *cmd;
>> +	int ret;
>> +	u16 res_code;
>> +
>> +	cmd_skb = qtnf_cmd_alloc_new_cmdskb(vif->mac->macid, vif->vifid,
>> +					    QLINK_CMD_START_CAC,
>> +					    sizeof(*cmd));
>> +	if (unlikely(!cmd_skb))
>> +		return -ENOMEM;
>
> The unlikely() looks pretty useless here. likely() and unlikely() are
> supposed to be used in cases where it matters and the improvment can be
> measured, I doubt that's the case here.

But no need to resend just because of this.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH 10/10] qtnfmac: support MAC address based access control
From: Kalle Valo @ 2017-12-04 15:01 UTC (permalink / raw)
  To: Sergey Matyukevich
  Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
In-Reply-To: <20171113102815.11254-11-sergey.matyukevich.os@quantenna.com>

Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:

> From: Vasily Ulyanov <vulyanov@quantenna.com>
>
> This allows a running AP to blacklist STAs by their MAC addresses
> respecting the configured policy (either accept or deny unless listed).
> It can be setup on .start_ap or with .set_mac_acl commands.
>
> Signed-off-by: Vasily Ulyanov <vulyanov@quantenna.com>

[...]

> @@ -918,6 +933,7 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, struct qtnf_wmac *mac)
>  	wiphy->max_scan_ie_len = QTNF_MAX_VSIE_LEN;
>  	wiphy->mgmt_stypes = qtnf_mgmt_stypes;
>  	wiphy->max_remain_on_channel_duration = 5000;
> +	wiphy->max_acl_mac_addrs = mac->macinfo.max_acl_mac_addrs;
>  
>  	wiphy->iface_combinations = iface_comb;
>  	wiphy->n_iface_combinations = 1;
> @@ -932,6 +948,9 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, struct qtnf_wmac *mac)
>  			WIPHY_FLAG_AP_UAPSD |
>  			WIPHY_FLAG_HAS_CHANNEL_SWITCH;
>  
> +	if (wiphy->max_acl_mac_addrs > 0)
> +		wiphy->flags |= WIPHY_FLAG_HAVE_AP_SME;

Conditonally enabling WIPHY_FLAG_HAVE_AP_SME looks somewhat suspicious
to me and from a quick search I don't see any other driver doing
something similar. Can you explain why AP_SME is related to MAC ACL?

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH v8 0/3] mt76: add new wireless driver for MediaTek MT76x2 PCIe chips
From: Kalle Valo @ 2017-12-04 15:04 UTC (permalink / raw)
  To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <20171121095053.82673-1-nbd@nbd.name>

Felix Fietkau <nbd@nbd.name> writes:

> Changes since v7:
> - Fix build errors
>
> Changes since v6:
> - DT documentation fixes
> - Add LED configuration
> - PHY gain calibration fixes
> - Endian fixes
> - Tx status processing fixes
> - EEPROM validation fixes
> - IBSS RSN fix
> - AP mode powersave delivery fix
>
> Changes since v5:
> - Adjust for mac80211 API changes
> - EEPROM parsing fixes
> - Ad-hoc mode WPA2 fixes
>
> Changes since v4:
> - Cleanups suggested by Stanislaw Gruszka
> - Device tree fixes suggested by Rob Herring
> - EEPROM MAC address parsing fix
>
> Changes since v3:
> - DFS fixes
> - stability fixes
> - use wiphy_read_of_freq_limits
>
> Changes since v2:
> - lots of checkpatch cleanups
> - various tx path (and other) fixes
> - use the new bitfield API
> - documented device tree bindings
>
> Felix Fietkau (3):
>   Documentation: dt: net: add mt76 wireless device binding
>   mt76: add common code shared between multiple chipsets
>   mt76: add driver code for MT76x2e

Looking very good to me. Unless I hear any objections I'm planning to
apply this within the next few days.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH v2] mwl8k: Expand non-DFS 5G channels
From: Kalle Valo @ 2017-12-04 15:13 UTC (permalink / raw)
  To: Weixiao Zhang
  Cc: Lennert Buytenhek, Johannes Berg, Andrew Zaborowski,
	linux-wireless, netdev, linux-kernel
In-Reply-To: <20171116075955.qbbqhwqn4lys3xco@ximibaba.lan>

Weixiao Zhang <waveletboy@gmail.com> writes:

> Add non-DFS 5G upper channels (149-165) besides existed 4 lower channels
> (36, 40, 44, 48).
> { .band = NL80211_BAND_5GHZ, .center_freq = 5745, .hw_value = 149, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5765, .hw_value = 153, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5785, .hw_value = 157, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5805, .hw_value = 161, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5825, .hw_value = 165, },
>
> Signed-off-by: Weixiao Zhang <waveletboy@gmail.com>

You don't need to copy the code from the patch to the commit log, I'll
remove that when I commit this.

-- 
Kalle Valo

^ permalink raw reply

* Re: [PATCH INTERNAL V2 1/1] brcmfmac: add console log support with configurable read size
From: Kalle Valo @ 2017-12-04 15:15 UTC (permalink / raw)
  To: Li Jin
  Cc: Wright Feng, Chi-Hsien Lin, Hante Meuleman, Franky Lin,
	Arend van Spriel, linux-kernel, netdev, brcm80211-dev-list,
	brcm80211-dev-list.pdl, linux-wireless, Jason Uy
In-Reply-To: <1511313990-19334-1-git-send-email-li.jin@broadcom.com>

Li Jin <li.jin@broadcom.com> writes:

> From: Jason Uy <jason.uy@broadcom.com>
>
> Add support for configurable read size so that older wifi
> chips that have size restrictions can be supported.
>
> Signed-off-by: Jason Uy <jason.uy@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Li Jin <li.jin@broadcom.com>

Arend, am I supposed to apply this even if there's this "INTERNAL" tag
in the Subject?

-- 
Kalle Valo

^ permalink raw reply

* Re: Wifi RTL8723bu driver test: failed to scan
From: Mylene JOSSERAND @ 2017-12-04 15:54 UTC (permalink / raw)
  To: Jes Sorensen
  Cc: kvalo, linux-wireless, netdev, Thomas Petazzoni, Maxime Ripard
In-Reply-To: <75669dd0-1f25-fc7e-4a4d-a5549aeeb2cf@gmail.com>

Hello,

Le Tue, 28 Nov 2017 11:14:10 -0500,
Jes Sorensen <jes.sorensen@gmail.com> a écrit :

> On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> > Hello Jes Sorensen,
> > 
> > I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> > SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> > driver RTL8723BU for this USB dongle.
> > 
> > Currently, I am only testing the Wifi and the mainline driver
> > (kernel 4.14-rc7) does not seem to work. At least, the scanning
> > does not output anything.
> > 
> > I tested the driver recommended by LM Technologies [3] and it works
> > fine (scan, connect and ping are ok). Before investigating on the
> > differences between these two drivers, do you have any idea about
> > this issue?
> > 
> > Here are the commands and output I got with mainline's driver:  
> 
> I have not looked at the driver these LM Technologies people are
> referring to, but I am guessing it's the vendor code.

Yes, it is.

> 
> 8723bu is a little dicey because it has BT in the chip and if you
> enable that the two drivers need to interact, which rtl8xxxu
> currently doesn't know about. Check your dmesg output to make sure
> you don't have some BT thing loaded hijacking the chip.

Okay, I was also testing the BT so maybe, it was the case. I will
have a try without any BT drivers.

Anyway, thank you for your help!

Best regards,

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* RE: [PATCH INTERNAL V2 1/1] brcmfmac: add console log support with configurable read size
From: Li Jin @ 2017-12-04 17:11 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Wright Feng, Chi-Hsien Lin, Hante Meuleman, Franky Lin,
	Arend Van Spriel, linux-kernel, netdev, brcm80211-dev-list,
	BRCM80211-DEV-LIST,PDL, linux-wireless, Jason Uy
In-Reply-To: <87o9nejzic.fsf@purkki.adurom.net>

Hi Kalle,

Apologies. The title of this patch should be EXTERNAL. I put down INTERNAL
by mistake.

Thanks!
Li

-----Original Message-----
From: Kalle Valo [mailto:kvalo@codeaurora.org]
Sent: Monday, December 4, 2017 7:15 AM
To: Li Jin
Cc: Wright Feng; Chi-Hsien Lin; Hante Meuleman; Franky Lin; Arend van
Spriel; linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
brcm80211-dev-list@cypress.com; brcm80211-dev-list.pdl@broadcom.com;
linux-wireless@vger.kernel.org; Jason Uy
Subject: Re: [PATCH INTERNAL V2 1/1] brcmfmac: add console log support
with configurable read size

Li Jin <li.jin@broadcom.com> writes:

> From: Jason Uy <jason.uy@broadcom.com>
>
> Add support for configurable read size so that older wifi chips that
> have size restrictions can be supported.
>
> Signed-off-by: Jason Uy <jason.uy@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Li Jin <li.jin@broadcom.com>

Arend, am I supposed to apply this even if there's this "INTERNAL" tag in
the Subject?

--
Kalle Valo

^ permalink raw reply

* [PATCH] rtl8187: add master mode
From: Gabriele Gristina @ 2017-12-04 18:12 UTC (permalink / raw)
  To: linux-wireless; +Cc: Herton Ronaldo Krzesinski, Hin-Tak Leung, Larry Finger

This patch add the master mode to rtl8187 wireless driver.

Signed-off-by: Gabriele Gristina <gabriele.gristina@gmail.com>

---

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
index 121b94f09714..8ef22f4382ae 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -1113,6 +1113,7 @@ static int rtl8187_add_interface(struct ieee80211_hw *dev,
  goto exit;

  switch (vif->type) {
+ case NL80211_IFTYPE_AP:
  case NL80211_IFTYPE_STATION:
  case NL80211_IFTYPE_ADHOC:
  break;
@@ -1602,7 +1603,8 @@ static int rtl8187_probe(struct usb_interface *intf,
  priv->rfkill_mask = RFKILL_MASK_8198;
  }
  dev->vif_data_size = sizeof(struct rtl8187_vif);
- dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+ dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_AP) |
+       BIT(NL80211_IFTYPE_STATION) |
        BIT(NL80211_IFTYPE_ADHOC) ;

  wiphy_ext_feature_set(dev->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);

^ permalink raw reply related

* Re: [PATCH v8 0/3] mt76: add new wireless driver for MediaTek MT76x2 PCIe chips
From: Felix Fietkau @ 2017-12-04 18:50 UTC (permalink / raw)
  To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87wp22jzzb.fsf@purkki.adurom.net>

On 2017-12-04 16:04, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> writes:
> 
>> Changes since v7:
>> - Fix build errors
>>
>> Changes since v6:
>> - DT documentation fixes
>> - Add LED configuration
>> - PHY gain calibration fixes
>> - Endian fixes
>> - Tx status processing fixes
>> - EEPROM validation fixes
>> - IBSS RSN fix
>> - AP mode powersave delivery fix
>>
>> Changes since v5:
>> - Adjust for mac80211 API changes
>> - EEPROM parsing fixes
>> - Ad-hoc mode WPA2 fixes
>>
>> Changes since v4:
>> - Cleanups suggested by Stanislaw Gruszka
>> - Device tree fixes suggested by Rob Herring
>> - EEPROM MAC address parsing fix
>>
>> Changes since v3:
>> - DFS fixes
>> - stability fixes
>> - use wiphy_read_of_freq_limits
>>
>> Changes since v2:
>> - lots of checkpatch cleanups
>> - various tx path (and other) fixes
>> - use the new bitfield API
>> - documented device tree bindings
>>
>> Felix Fietkau (3):
>>   Documentation: dt: net: add mt76 wireless device binding
>>   mt76: add common code shared between multiple chipsets
>>   mt76: add driver code for MT76x2e
> 
> Looking very good to me. Unless I hear any objections I'm planning to
> apply this within the next few days.
Great news, thanks. Please also apply the two patches from "kbuild test
robot" that were sent in response to v7 - they still apply to v8.

- Felix

^ permalink raw reply

* Re: AP6335 with mainline kernel
From: Vanessa Maegima @ 2017-12-04 19:00 UTC (permalink / raw)
  To: arend.vanspriel@broadcom.com, van.ayumi@gmail.com
  Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com
In-Reply-To: <5A1FFA17.6000703@broadcom.com>

SGkgQXJlbmQsDQoNCk9uIFF1aSwgMjAxNy0xMS0zMCBhdCAxMzozMSArMDEwMCwgQXJlbmQgdmFu
IFNwcmllbCB3cm90ZToNCj4gT24gMTEvMjMvMjAxNyA0OjI0IFBNLCBWYW5lc3NhIE1hZWdpbWEg
d3JvdGU6DQo+ID4gDQo+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAN
Cj4gPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiA+IEJ1aWxkcm9vdDoNCj4gPiA+ID4gPiA+ID4g
IyBkbWVzZyB8IGdyZXAgYnJjbWZtYWMNCj4gPiA+ID4gPiA+ID4gW8KgwqDCoMKgNS4zNDMxMThd
IGJyY21mbWFjOiBicmNtZl9md19tYXBfY2hpcF90b19uYW1lOiB1c2luZw0KPiA+ID4gPiA+ID4g
PiBicmNtL2JyY21mbWFjNDMzOS1zZGlvLmJpbiBmb3IgY2hpcCAweDAwNDMzDQo+ID4gPiA+ID4g
PiA+IDkoMTcyMDkpIHJldiAweDAwMDAwMg0KPiA+ID4gPiA+ID4gPiBbwqDCoMKgwqA2LjQyMDA3
MF0gYnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6IEhUIEF2YWlsDQo+ID4gPiA+ID4gPiA+IHRp
bWVvdXQNCj4gPiA+ID4gPiA+ID4gKDEwMDAwMDApOg0KPiA+ID4gPiA+ID4gPiBjbGtjdGwgMHg1
MA0KPiA+ID4gPiA+ID4gPiBbwqDCoMKgwqA2LjQyNzcyMl0gYnJjbWZtYWM6DQo+ID4gPiA+ID4g
PiA+IGJyY21mX3NkaW9faHRjbGs6wqDCoMKgcG11Y29udHJvbMKgwqDCoD0NCj4gPiA+ID4gPiA+
ID4gMDE3NzQzODENCj4gPiA+ID4gPiA+ID4gW8KgwqDCoMKgNi40MzQ4NjVdIGJyY21mbWFjOg0K
PiA+ID4gPiA+ID4gPiBicmNtZl9zZGlvX2h0Y2xrOsKgwqDCoHBtdXN0YXR1c8KgwqDCoMKgPQ0K
PiA+ID4gPiA+ID4gPiAwMDAwMDAyYQ0KPiA+ID4gPiA+ID4gPiBbwqDCoMKgwqA2LjQ0MTE3NF0g
YnJjbWZtYWM6IGJyY21mX3NkaW9faHRjbGs6wqDCoMKgbWluX3Jlc19tYXNrDQo+ID4gPiA+ID4g
PiA+ID0NCj4gPiA+ID4gPiA+ID4gMGZjYWZmNzcNCj4gPiA+ID4gPiA+ID4gW8KgwqDCoMKgNi40
NDczNzldIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0Y2xrOsKgwqDCoG1heF9yZXNfbWFzaw0KPiA+
ID4gPiA+ID4gPiA9DQo+ID4gPiA+ID4gPiA+IDBmY2VmZjc3DQo+IEl0IHRvb29rIG1lIGEgd2hp
bGUgdG8gbG9vayBpbnRvIHRoaXMuIFVuZm9ydHVuYXRlbHkgSSBkbyBub3QgaGF2ZSBhwqANCj4g
NDMzOSB0byByZXBsaWNhdGUgeW91ciBpc3N1ZS4gVGhlIGNsb3Nlc3QgSSBoYXZlIGlzIGEgNDMz
NS4gV2hhdA0KPiBsb29rc8KgDQo+IHdyb25nIGhlcmUgaXMgdGhlIG1heF9yZXNfbWFzayBiZWNh
dXNlIHRoZSBIVCBBdmFpbCByZXNvdXJjZSBpcyBiaXQNCj4gMjnCoA0KPiB3aGljaCBuZWVkcyB0
byBiZSBzZXQgaW4gbWF4X3Jlc19tYXNrIGluIG9yZGVyIHRvIG1ha2UgdGhlIHJlcXVlc3QNCj4g
d29yay7CoA0KPiBPbiBteSA0MzM1IHRoZSBtYXhfcmVzX21hc2sgaXMgMHg3ZmZmZmZmZiBiZWZv
cmUgY2FsbGluZ8KgDQo+IGJyY21mX3NkaW9faHRjbGsoKS4gU28gdGhhdCBpcyB0aGUgY2F1c2Ug
b2YgdGhlIGZhaWx1cmUgaW7CoA0KPiBicmNtZl9zZGlvX2h0Y2xrKCkuIEhvd2V2ZXIsIG5vdyB0
aGUgcXVlc3Rpb24gaXMgd2h5IGl0IGlzIG5vdA0KPiBwcm9wZXJseSBzZXQuDQo+IA0KPiBCZXR3
ZWVuIHlvdXIgZGV2aWNlIGFuZCBtaW5lIHRoZXJlIGlzIG9uY2UgZGlzY3JlcGFuY3kgaW4gdGhl
DQo+IHBtdWNvbnRyb2zCoA0KPiByZWdpc3RlciwgaWUuIGJpdCA5IGlzIHNldCBmb3IgeW91ciBk
ZXZpY2UuIEFjY29yZGluZyB0aGUNCj4gZG9jdW1lbnRhdGlvbsKgDQo+IHRoZSBwb3dlci1vbiBy
ZXNldCB2YWx1ZSBmb3IgdGhpcyBiaXQgaXMgMCBhbmQgSSBkb24ndCBzZWVuIGFueSBjb2RlDQo+
IGluwqANCj4gb3VyIHByb3ByaWV0YXJ5IGRyaXZlciB0b3VjaGluZyBpdC4NCj4gDQo+ID4gDQo+
ID4gU29ycnkgZm9yIHRoZSBkZWxheWVkIGFuc3dlciwgSSBoYWQgc29tZSB0cm91YmxlIHRvIGNv
cHkgdGhlDQo+ID4gc3ltbGlua3MNCj4gPiBmaWxlcyBjb3JyZXRseSBmcm9tIC9zeXMvY2xhc3Mv
ZGV2Y29yZWR1bXAuDQo+ID4gDQo+ID4gSSB1cGxvYWRlZCB0aGlzIGZvbGRlciB0bzogaHR0cHM6
Ly9lbWVhMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bA0KPiA+IG9vay5jb20vP3VybD1odHRw
cyUzQSUyRiUyRmRyaXZlLmdvb2dsZS5jb20lMkZvcGVuJTNGaWQlM0QxZm9zYWhqTE4NCj4gPiAx
SyZkYXRhPTAyJTdDMDElN0N2YW5lc3NhLm1hZWdpbWElNDBueHAuY29tJTdDYjY0M2U1Nzg3NmU0
NDE0MGFhMzAwDQo+ID4gOGQ1MzdlZTQ0YWElN0M2ODZlYTFkM2JjMmI0YzZmYTkyY2Q5OWM1YzMw
MTYzNSU3QzAlN0MwJTdDNjM2NDc2NDE4OA0KPiA+IDQ5NDY0MjE0JnNkYXRhPUJyc0R6ME5jbTc4
NmcxNjlUUU9xRmxiV3V5bFIxcGMxSmtsRWtxZUwlMkZBMCUzRCZyZXMNCj4gPiBlcnZlZD0wDQo+
ID4gSTVOS1M1OV9hUFpkSExwRU5QRkh0Sw0KPiBUaGF0IHdvcmtlZCBuaWNlbHkuIFNvIHRoZSBm
aXJtd2FyZSBzZWVtcyB0byBjcmFzaCB2ZXJ5IGVhcmx5LiBJDQo+IGhhdmXCoA0KPiByZWJ1aWx0
IHRoZSBmaXJtd2FyZSB0byBwcm92aWRlIG1lIG1vcmUgaW5mby4gQ2FuIHlvdSByZWRvIHRoZcKg
DQo+IGRldmNvcmVkdW1wIHRyaWNrIHdpdGggdGhhdCBmaXJtd2FyZS4NCj4gDQo+IFJlZ2FyZHMs
DQo+IEFyZW5kDQoNClRoYW5rcyBmb3IgeW91ciByZXBseSENCg0KSSB0cmllZCB5b3VyIG5ldyBm
aXJtd2FyZSBhbmQgaGVyZSBpcyB0aGUgb3V0cHV0IChuZXdfZmlybXdhcmUgZm9sZGVyKToNCmh0
dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9kcml2ZS9mb2xkZXJzLzFmb3NhaGpMTjFLSTVOS1M1OV9h
UFpkSExwRU5QRkh0DQpLDQoNClRoYW5rcyENCg0KUmVnYXJkcywNClZhbmVzc2E=

^ permalink raw reply

* Re: [PATCH] rtl8187: add master mode
From: Hin-Tak Leung @ 2017-12-04 20:43 UTC (permalink / raw)
  To: linux-wireless, Gabriele Gristina; +Cc: Herton Ronaldo Krzesinski, Larry Finger
In-Reply-To: <831356585.2629841.1512420230218.ref@mail.yahoo.com>

--------------------------------------------
On Mon, 4/12/17, Gabriele Gristina <gabriele.gristina@gmail.com> wrote:

> This patch add the master mode to rtl8187
> wireless driver.
 
> Signed-off-by: Gabriele Gristina <gabriele.gristina@gmail.com>

Your two-line patch is most likely completely wrong... master mode is not just the driver claiming (and lying...) to support master mode. At least, it is extremely imcomplete.

We discussed this briefly some years ago; my impression of the discussion was that devices supporting master modes need to have some specific features which are not found in low-end devices (rtl818x being such). Although some of these necessities were foresaw to be possible to be implemented in software (i.e. the rest of the kernel in the core wifi stack) in a later stage.

I think Larry can say a bit more in this matter.

Hin-Tak

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox