RE: [PATCH v2 01/12] mwifiex: check tx_hw_pending before downloading sleep confirm

Hi > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2016年11月4日 0:12 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; Amitkumar Karwar; Cathy Luo; > Shengzhen Li; Xinming Hu; Wei-Ning Huang > Subject: Re: [PATCH v2

[PATCH RESEND v2 01/11] mwifiex: check tx_hw_pending before downloading sleep confirm

abort. This patch will only allow downloading sleep confirm when no tx done interrupt is pending in the hardware. Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Shengzhen Li <s...@marvell.com> Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Amitkumar Kar

[PATCH RESEND v2 05/11] mwifiex: don't pretend to resume while remove()'ing

From: Brian Norris The device core will not allow suspend() to race with remove(). Signed-off-by: Brian Norris --- v2: Same as v1 --- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 - drivers/net/wireless/marvell/mwifiex/sdio.c | 3 ---

[PATCH RESEND v2 02/11] mwifiex: complete blocked power save handshake in main process

Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Shengzhen Li <s...@marvell.com> Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Amitkumar Karwar <akar...@marvell.com> --- v2: 1. remove redudant check(Brain) 2. reorgnized to follow tx_hw_pending p

[PATCH RESEND v2 09/11] mwifiex: sdio: don't check for NULL sdio_func

From: Brian Norris sdio_func is retrieved via container_of() and should never be NULL. Checking for NULL just makes the logic more confusing than necessary. Stop doing that. Signed-off-by: Brian Norris --- v2: Same as v1 ---

[PATCH RESEND v2 03/11] mwifiex: resolve races between async FW init (failure) and device removal

From: Brian Norris It's possible for the FW init sequence to fail, which will trigger a device cleanup sequence in mwifiex_fw_dpc(). This sequence can race with device suspend() or remove() (e.g., reboot or unbind), and can trigger use-after-free issues. Currently, this

[PATCH RESEND v2 11/11] mwifiex: pcie: stop checking for NULL adapter->card

From: Brian Norris It should never be NULL here, and to think otherwise makes things confusing. Signed-off-by: Brian Norris --- v2: Same as v1 --- drivers/net/wireless/marvell/mwifiex/pcie.c | 55 + 1 file

[PATCH RESEND v2 10/11] mwifiex: stop checking for NULL drvata/intfdata

From: Brian Norris These are never NULL, so stop making people think they might be. I don't change this for SDIO because SDIO has a racy card-reset handler that reallocates this struct. I'd rather not touch that mess right now. Signed-off-by: Brian Norris

[PATCH RESEND v2 07/11] mwifiex: reset card->adapter during device unregister

From: Xinming Hu <h...@marvell.com> card->adapter gets initialized in mwifiex_register_dev(). As it's not cleared in mwifiex_unregister_dev(), we may end up accessing the memory which is already free in below scenario. Scenario: Driver initialization is failed due to incorrect firmwar

[PATCH RESEND v2 06/11] mwifiex: resolve suspend() race with async FW init failure

From: Brian Norris Signed-off-by: Brian Norris --- v2: Same as v1 --- drivers/net/wireless/marvell/mwifiex/pcie.c | 12 ++-- drivers/net/wireless/marvell/mwifiex/sdio.c | 12 ++-- drivers/net/wireless/marvell/mwifiex/usb.c |

[PATCH RESEND v2 08/11] mwifiex: usb: handle HS failures

From: Brian Norris SDIO and PCIe drivers handle this. Let's imitate it. Not tested. Signed-off-by: Brian Norris --- v2: Same as v1 --- drivers/net/wireless/marvell/mwifiex/usb.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-)

[PATCH RESEND v2 04/11] mwifiex: remove redundant pdev check in suspend/resume handlers

From: Amitkumar Karwar to_pci_dev() would just do struct offset arithmetic on struct device to get 'pdev' pointer. We never get NULL pdev pointer. Signed-off-by: Amitkumar Karwar Signed-off-by: Brian Norris --- v2: Same as v1

RE: [PATCH 01/12] mwifiex: fix power save issue when suspend

age- > From: linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Brian Norris > Sent: 2016年11月1日 7:57 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; Amitkumar Karwar; Cathy Luo; > Shengzhen Li > Subject: Re: [P

[PATCH v2 02/12] mwifiex: complete blocked power save handshake in main process

--- v2: 1. remove redudant check(Brain) 3. reorgnized to follow tx_hw_pending patch --- Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Shengzhen Li <s...@marvell.com> Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Amitkumar Karwar <akar...@ma

[PATCH v2 01/12] mwifiex: check tx_hw_pending before downloading sleep confirm

abort. This patch will only allow downloading sleep confirm when no tx done interrupt is pending in the hardware. --- v2: address format issues(Brain) --- Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Shengzhen Li <s...@marvell.com> Signed-off-by: Xinming Hu <h...@ma

RE: [PATCH 02/12] mwifiex: check tx_hw_pending before downloading sleep confirm

Hi Brain, > -Original Message- > From: linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Brian Norris > Sent: 2016年11月1日 8:15 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; Amitkumar Karwar; Cathy L

RE: [PATCH v2 1/5] mwifiex: remove redundant condition in main process

Hi, We have include below change in latest submit https://patchwork.kernel.org/patch/9407283/ Please drop this patch. > -Original Message- > From: linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Brian Norris > Sent: 2016年10月28日 2:36 >

RE: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

Hi Dmitry, > -Original Message- > From: linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov > Sent: 2016年10月28日 1:44 > To: Amitkumar Karwar > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam; >

[PATCH 06/12] mwifiex: don't pretend to resume while remove()'ing

From: Brian Norris The device core will not allow suspend() to race with remove(). Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 - drivers/net/wireless/marvell/mwifiex/sdio.c | 3 ---

[PATCH 08/12] mwifiex: reset card->adapter during device unregister

From: Xinming Hu <h...@marvell.com> card->adapter gets initialized in mwifiex_register_dev(). As it's not cleared in mwifiex_unregister_dev(), we may end up accessing the memory which is already free in below scenario. Scenario: Driver initialization is failed due to incorrect firmwar

[PATCH 10/12] mwifiex: sdio: don't check for NULL sdio_func

From: Brian Norris sdio_func is retrieved via container_of() and should never be NULL. Checking for NULL just makes the logic more confusing than necessary. Stop doing that. Signed-off-by: Brian Norris ---

[PATCH 07/12] mwifiex: resolve suspend() race with async FW init failure

From: Brian Norris Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 11 +-- drivers/net/wireless/marvell/mwifiex/sdio.c | 11 +-- drivers/net/wireless/marvell/mwifiex/usb.c | 12 ++-- 3

[PATCH 03/12] mwifiex: don't do unbalanced free()'ing in cleanup_if()

From: Brian Norris The cleanup_if() callback is the inverse of init_if(). We allocate our 'card' interface structure in the probe() function, but we free it in cleanup_if(). That gives a few problems: (a) we leak this memory if probe() fails before we reach init_if()

[PATCH 04/12] mwifiex: resolve races between async FW init (failure) and device removal

From: Brian Norris It's possible for the FW init sequence to fail, which will trigger a device cleanup sequence in mwifiex_fw_dpc(). This sequence can race with device suspend() or remove() (e.g., reboot or unbind), and can trigger use-after-free issues. Currently, this

[PATCH 11/12] mwifiex: stop checking for NULL drvata/intfdata

From: Brian Norris These are never NULL, so stop making people think they might be. I don't change this for SDIO because SDIO has a racy card-reset handler that reallocates this struct. I'd rather not touch that mess right now. Signed-off-by: Brian Norris

[PATCH 12/12] mwifiex: pcie: stop checking for NULL adapter->card

From: Brian Norris It should never be NULL here, and to think otherwise makes things confusing. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 55 + 1 file changed, 24 insertions(+),

[TEST V2 GIT-SEND-EMAIL,PATCH 01/11] mwifiex: fix power save issue when suspend

From: Shengzhen Li This patch fixes a corner case for "FROMLIST: mwifiex: fix corner case power save issue", main process will check the power save condition in PS_PRE_SLEEP status so the sleep handshake could continue. Signed-off-by: Shengzhen Li ---

[PATCH 02/12] mwifiex: check tx_hw_pending before downloading sleep confirm

From: Shengzhen Li This patch will only allow downloading sleep confirm when no tx done interrupt is pending in the hardware. Signed-off-by: Cathy Luo Signed-off-by: Shengzhen Li Change-Id: I6d6955b4a2de0ad791ca28f0f635d636a2c7e406 ---

RE: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 2016年11月4日 2:49 > To: Brian Norris > Cc: Xinming Hu; Amitkumar Karwar; linux-wireless@vger.kernel.org; Cathy Luo; > Nishant Sarmukadam; raja...@google.com > Subject: Re: [PATCH

[PATCH v2 06/12] mwifiex: don't pretend to resume while remove()'ing

From: Brian Norris The device core will not allow suspend() to race with remove(). --- v2: Same as v1 --- Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 - drivers/net/wireless/marvell/mwifiex/sdio.c | 3

[PATCH v2 07/12] mwifiex: resolve suspend() race with async FW init failure

From: Brian Norris --- v2: Same as v1 --- Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 11 +-- drivers/net/wireless/marvell/mwifiex/sdio.c | 11 +-- drivers/net/wireless/marvell/mwifiex/usb.c

[PATCH v2 12/12] mwifiex: pcie: stop checking for NULL adapter->card

From: Brian Norris It should never be NULL here, and to think otherwise makes things confusing. --- v2: Same as v1 --- Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 55 + 1 file

[PATCH v2 10/12] mwifiex: sdio: don't check for NULL sdio_func

From: Brian Norris sdio_func is retrieved via container_of() and should never be NULL. Checking for NULL just makes the logic more confusing than necessary. Stop doing that. --- v2: Same as v1 --- Signed-off-by: Brian Norris ---

[PATCH v2 03/12] mwifiex: don't do unbalanced free()'ing in cleanup_if()

From: Brian Norris The cleanup_if() callback is the inverse of init_if(). We allocate our 'card' interface structure in the probe() function, but we free it in cleanup_if(). That gives a few problems: (a) we leak this memory if probe() fails before we reach init_if()

[PATCH v2 08/12] mwifiex: reset card->adapter during device unregister

From: Xinming Hu <h...@marvell.com> card->adapter gets initialized in mwifiex_register_dev(). As it's not cleared in mwifiex_unregister_dev(), we may end up accessing the memory which is already free in below scenario. Scenario: Driver initialization is failed due to incorrect firmwar

[PATCH v2 11/12] mwifiex: stop checking for NULL drvata/intfdata

From: Brian Norris These are never NULL, so stop making people think they might be. I don't change this for SDIO because SDIO has a racy card-reset handler that reallocates this struct. I'd rather not touch that mess right now. --- v2: Same as v1 --- Signed-off-by:

[PATCH v2 09/12] mwifiex: usb: handle HS failures

From: Brian Norris SDIO and PCIe drivers handle this. Let's imitate it. Not tested. --- v2: Same as v1 --- Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/usb.c | 9 - 1 file changed, 8 insertions(+), 1

[PATCH v2 04/12] mwifiex: resolve races between async FW init (failure) and device removal

From: Brian Norris It's possible for the FW init sequence to fail, which will trigger a device cleanup sequence in mwifiex_fw_dpc(). This sequence can race with device suspend() or remove() (e.g., reboot or unbind), and can trigger use-after-free issues. Currently, this

[PATCH v2 05/12] mwifiex: remove redundant pdev check in suspend/resume handlers

From: Amitkumar Karwar to_pci_dev() would just do struct offset arithmetic on struct device to get 'pdev' pointer. We never get NULL pdev pointer. --- v2: Same as v1 --- Signed-off-by: Amitkumar Karwar Signed-off-by: Brian Norris

[PATCH 2/3] mwifiex: using general print function during device intialization

From: Xinming Hu <h...@marvell.com> adapter->dev is initialized after mwifiex_register done, before that print message by general pr_* function Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Amitkumar Karwar <akar...@marvell.com> --- drivers/net/wireless/marvel

[PATCH 1/3] mwifiex: remove unnecessary wakeup interrupt number sanity check

From: Xinming Hu <h...@marvell.com> Sanity check of interrupt number in interrupt handler is unnecessary and confusion, remove it. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Amitkumar Karwar <akar...@marvell.com> --- drivers/net/wireless/marvell/mwifiex/main

RE: Re: [PATCH 1/3] mwifiex: remove unnecessary wakeup interrupt number sanity check

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月4日 2:34 > To: Dmitry Torokhov > Cc: Xinming Hu; Linux Wireless; Kalle Valo; Rajat Jain; Amitkumar Karwar; > Cathy > Luo; Xinming Hu > Subject: [EXT] Re: [PA

[PATCH v2 3/4] mwifiex: pcie: correct scratch register name

From: Xinming Hu <h...@marvell.com> This patch correct pcie scratch register name, to keep the same with chipset side definition. Signed-off-by: Xinming Hu <h...@marvell.com> --- v2: code clean and prepare for next patch 4/4 --- drivers/net/wireless/marvell/mwifiex/pcie.c | 4 ++--

[PATCH v2 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

From: Xinming Hu <h...@marvell.com> A seperate wifi-only firmware was download during pcie function level reset. It is in fact the tail part of wifi/bt combo firmware. Per Brian's and Dmitry's suggestion, this patch extract the wifi part from combo firmware. After that, we can d

[PATCH v2 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

From: Xinming Hu <h...@marvell.com> mwifiex_dbg will do nothing before adapter->dev get assigned. several logs lost in this case. it can be avoided by fall back to pr_info. Signed-off-by: Xinming Hu <h...@marvell.com> --- v2: enhance adapter->dev null case.(Brain) --- dr

[PATCH v2 1/4] mwifiex: remove unnecessary wakeup interrupt number sanity check

From: Xinming Hu <h...@marvell.com> If wakeup interrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Reviewed-by: Dmitry Torokhov

RE: Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

Hi Dmitry, > -Original Message- > From: Dmitry Torokhov [mailto:d...@google.com] > Sent: 2017年4月1日 6:50 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Brian Norris; Rajat Jain; Amitkumar Karwar; > Cathy Luo; Xinming Hu > Subject: [EXT] Re: [PATCH 3/3] mwifiex:

RE:] Re: [3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

Hi Kalle, > -Original Message- > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: 2017年4月5日 18:47 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Brian Norris; Dmitry Torokhov; > raja...@google.com; Amitkumar Karwar; Cathy Luo; Xinming Hu > Subject: [EXT] Re

[PATCH v3 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

From: Xinming Hu <h...@marvell.com> mwifiex_dbg will do nothing before adapter->dev get assigned. several logs lost in this case. it can be avoided by fall back to pr_info. Signed-off-by: Xinming Hu <h...@marvell.com> Reviewed-by: Brian Norris <briannor...@chromium.org>

RE: Re: [PATCH v2 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

Hi Dmitry, > -Original Message- > From: Dmitry Torokhov [mailto:d...@google.com] > Sent: 2017年4月8日 1:28 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Brian Norris; Rajat Jain; Amitkumar Karwar; > Cathy Luo; Xinming Hu > Subject: [EXT] Re: [PATCH v2 2/4] mwifiex:

[PATCH v3 3/4] mwifiex: pcie: correct scratch register name

From: Xinming Hu <h...@marvell.com> This patch correct pcie scratch register name, to keep the same with chipset side definition. Signed-off-by: Xinming Hu <h...@marvell.com> --- v2: code clean and prepare for next patch 4/4 v3: same as v2 --- drivers/net/wireless/marvell/mwifiex

[PATCH v3 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

From: Xinming Hu <h...@marvell.com> A seperate wifi-only firmware was download during pcie function level reset. It is in fact the tail part of wifi/bt combo firmware. Per Brian's and Dmitry's suggestion, this patch extract the wifi part from combo firmware. After that, we can d

[PATCH v3 1/4] mwifiex: remove unnecessary wakeup interrupt number sanity check

From: Xinming Hu <h...@marvell.com> If wakeup interrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Reviewed-by: Dmitry Torokhov

[PATCH v4 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

From: Xinming Hu <h...@marvell.com> mwifiex_dbg will do nothing before adapter->dev get assigned. several logs lost in this case. it can be avoided by fall back to pr_info. Signed-off-by: Xinming Hu <h...@marvell.com> Reviewed-by: Brian Norris <briannor...@chromium.org>

RE: Re: [PATCH v3 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月11日 9:37 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; > Amitkumar Karwar; Cathy Luo; Xinming Hu; Ganapathi Bhat > Subject:

[PATCH v4 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

From: Xinming Hu <h...@marvell.com> A seprate wifi-only firmware was download during pcie function level reset. It is in fact the tail part of wifi/bt combo firmware. Per Brian's and Dmitry's suggestion, this patch extract the wifi part from combo firmware. After that, we can d

[PATCH v4 3/4] mwifiex: pcie: correct scratch register name

From: Xinming Hu <h...@marvell.com> This patch correct pcie scratch register name, to keep the same with chipset side definition. Signed-off-by: Xinming Hu <h...@marvell.com> --- v2: code clean and prepare for next patch 4/4 v4: same as v2, v3 --- drivers/net/wireless/marvell/mw

[PATCH v4 1/4] mwifiex: remove unnecessary wakeup interrupt number sanity check

From: Xinming Hu <h...@marvell.com> If wakeup interrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Reviewed-by: Dmitry Torokhov

RE: Re: Re: Re: [PATCH v3 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月15日 0:56 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; > Amitkumar Karwar; Cathy Luo; Ganapathi Bhat > Subject: [EXT] Re:

RE: [PATCH v5 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

Hi, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月14日 4:11 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; Cathy > Luo; > Xinming Hu; Ganapathi Bhat > Subject: [EXT] [PATCH v5 4/4

RE: Re: Re: [PATCH v3 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月14日 1:50 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; > Amitkumar Karwar; Cathy Luo; Ganapathi Bhat > Subject: [EXT]

RE: [EXT] Re: [PATCH v4 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

Hi Kalle, > -Original Message- > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: 2017年4月13日 21:59 > To: Xinming Hu > Cc: Linux Wireless; Brian Norris; Dmitry Torokhov; raja...@google.com; > Amitkumar Karwar; Cathy Luo; Xinming Hu; Ganapathi Bhat > Subject: [E

test send-email configuration please ignore

I am testing my send-email configuration, please ignore this mail. Thanks.

pull-request mwifiex-firmware 2017-03-11

to 59d72586fbaa71cdf3a9f0e0ea2bb169f80d9e6b: linux-firmware: update Marvell PCIe-USB8997 wifi-only firmware image (2017-03-11 02:31:18 -0800) Xinming Hu (1): linux-firmware: update Marvell PCIe-USB8997 wifi-only firmware image WHENCE

Re: [PATCH 2/3] mwifiex: using general print function during device intialization

> -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月4日 2:42 > To: Dmitry Torokhov > Cc: Xinming Hu; Linux Wireless; Kalle Valo; Rajat Jain; Amitkumar Karwar; > Cathy > Luo; Xinming Hu > Subject: [EXT] Re: [PATCH 2/3] mwif

RE: [EXT] Re: [PATCH 1/3] mwifiex: remove unnecessary wakeup interrupt number sanity check

Hi Dmitry, > -Original Message- > From: Dmitry Torokhov [mailto:d...@chromium.org] > Sent: 2017年4月1日 6:37 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Brian Norris; Rajat Jain; Amitkumar Karwar; > Cathy Luo; Xinming Hu > Subject: [EXT] Re: [PATCH 1/3] mwifie

RE: [EXT] Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年4月4日 2:49 > To: Dmitry Torokhov > Cc: Xinming Hu; Linux Wireless; Kalle Valo; Rajat Jain; Amitkumar Karwar; > Cathy > Luo; Xinming Hu > Subject: [EXT] Re: [PATCH 3

[v2 PATCH] mwifiex: correct IE parse during association

From: Xinming Hu <h...@marvell.com> It is observed that some IEs get missed during association. This patch correct the old IE parse code. sme->ie will be store as wpa ie, wps ie, wapi ie and gen ie accordingly. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-b

Re: [PATCH] mwifiex: correct IE parse during association

Hi Kalle, Thanks for the review, I have refactor code to avoid ugly indent in v2. Regards, Simon From: Kalle Valo <kv...@codeaurora.org> Sent: Friday, July 28, 2017 22:39 To: Xinming Hu Cc: Linux Wireless; Brian Norris; Dmitry Torokhov; raja...@goog

[PATCH 1/2] mwifiex: make addba request command clean

From: Xinming Hu <h...@marvell.com> uninitilized variable, such as .add_req_result might be magic stack value. Initialize the structure to make it clean. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> --- drivers/net/wireless/marvell

[PATCH 2/2] mwifiex: pcie: compatible with wifi-only image while extract wifi-part fw

From: Xinming Hu <h...@marvell.com> Sometimes, we might using wifi-only firmware with a combo firmware name, in this case, do not need to filter bluetooth part from header. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> --- drivers/ne

[PATCH] mwifiex: add module parameter to disable 40MHZ support in 2.4G band

From: Xinming Hu <h...@marvell.com> This patch provide a new module parameter disable_2g4_40m, with which driver will not report 40M capability for 2.4GHZ to cfg80211. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by:

[PATCH 1/2] mwifiex: Do not change bss_num in change_virtual_intf

From: Xinming Hu <h...@marvell.com> Commit "mwifiex: Do not change bss_type in change_virtual_intf" Keep original bss_type unchanged. bss_num should keep the same style, in this way. Unique tuple (bss_type, bss_num) will be able to locate the right priv structure. Signed-off-b

[PATCH 2/2] mwifiex: wrapper wps ie in pass through tlv

From: Xinming Hu <h...@marvell.com> This patch wrapper wps ie in pass through tlv, so that firmware could parse correctly. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Ganapathi Bhat <gb...@marvell.com> --- driv

RE: [PATCH] mwifiex: add module parameter to disable 40MHZ support in 2.4G band

Hi Arend/Kalle, > -Original Message- > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: 2017年8月3日 18:00 > To: Arend van Spriel > Cc: Xinming Hu; Linux Wireless; Brian Norris; Dmitry Torokhov; > raja...@google.com; Zhiyuan Yang; Tim Song; Cathy Luo; Ganapathi

[PATCH] mwifiex: p2p: use separate device address

From: Xinming Hu <h...@marvell.com> Per below statement about p2p device address in WFA P2P spec $2.4.3: The P2P Device Address of a P2P Device shall be its globally administered MAC address, or its globally administered MAC address with the locally administered bit set. This patch follow

[PATCH 3/3] mwifiex: debugfs: trigger device dump for usb interface

From: Xinming Hu <h...@marvell.com> This patch extend device_dump debugfs function to make it works for usb interface. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Ganapathi Bhat <gb...@marvell.com> --- driv

[PATCH 2/3] mwifiex: device dump support for usb interface

From: Xinming Hu <h...@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

[PATCH 1/3] mwifiex: refactor device dump code to make it generic for usb interface

From: Xinming Hu <h...@marvell.com> This patch refactor current device dump code to make it generic for subsequent implementation on usb interface. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Ganapathi Bhat

Re: [PATCH] mwifiex: usb: unlock on error in mwifiex_usb_tx_aggr_tmo()

Hi, > -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: 2017年7月10日 15:21 > To: Amitkumar Karwar; Xinming Hu > Cc: Nishant Sarmukadam; Ganapathi Bhat; Kalle Valo; > linux-wireless@vger.kernel.org; kernel-janit...@vger.kernel.org >

[PATCH] mwifiex: correct IE parse during association

From: Xinming Hu <h...@marvell.com> It is observed that some IEs get missed during association. This patch correct the old IE parse code. sme->ie will be store as wpa ie, wps ie, wapi ie and gen ie accordingly. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-b

[PATCH v2] mwifiex: add tdls uapsd support module parameter

From: Xinming Hu <h...@marvell.com> An issue about tdls uapsd was fixed in latest firmware, this patch add module parameter to control tdls uapsd support, which is default disabled, could be a workaround to the old firmware. At the same time, it is optional to enable this feature in specifi

[PATCH] mwifiex: add tdls uapsd support module parameter

From: Xinming Hu <h...@marvell.com> Add module parameter to control tdls uapsd support, which is default disabled. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> --- drivers/net/wireless/marvell/mwifiex/init.c| 5 + drivers/ne

Re: Re: [PATCH] mwifiex: add tdls uapsd support module parameter

Hi Brian, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年7月20日 4:10 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; Zhiyuan > Yang; Tim Song; Cathy Luo; Xinming Hu > Subject: [EXT] Re:

[PATCH] mwifiex: disable uapsd in tdls config

From: Xinming Hu <h...@marvell.com> Tdls uapsd support capability is default disabled during tdls setup, correspondingly it should also been disabled in tdls config. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by:

Re: Re: Re: [PATCH] mwifiex: add tdls uapsd support module parameter

Hi, > -Original Message- > From: Dmitry Torokhov [mailto:d...@google.com] > Sent: 2017年7月21日 1:29 > To: Brian Norris > Cc: Xinming Hu; Xinming Hu; Ganapathi Bhat; Linux Wireless; Kalle Valo; > raja...@google.com; Zhiyuan Yang; Tim Song; Cathy Luo > Subject: [EXT] Re

Re: [PATCH v2] mwifiex: add tdls uapsd support module parameter

Hi, Please drop this patch, as there is a replace version already. > -Original Message- > From: Xinming Hu [mailto:huxinming...@gmail.com] > Sent: 2017年7月20日 19:06 > To: Linux Wireless > Cc: Kalle Valo; Brian Norris; Dmitry Torokhov; raja...@google.com; Zhiyuan > Yan

[PATCH] mwifiex: p2p client using same data path as station

From: Xinming Hu <h...@marvell.com> P2p client act as a station, data will be queued by DA instead of RA. This patch pass the sanity check, so that p2p client share the same data path with infrastruction station mode. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by:

[PATCH] mwifiex: uap: enable 11d based on userspace configruation

From: Xinming Hu <h...@marvell.com> This patch check whether userspace beacon data include country ie, if so then download command to enable 11d setup in firmeare accordingly. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> --- dr

[v2 PATCH 2/2] mwifiex: pcie: compatible with wifi-only image while extract wifi-part fw

From: Xinming Hu <h...@marvell.com> Sometimes, we might using wifi-only firmware with a combo firmware name, in this case, do not need to filter bluetooth part from header. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Reviewe

Re: Re: [PATCH 2/2] mwifiex: pcie: compatible with wifi-only image while extract wifi-part fw

Hi Brian, Thanks for the review, fix below comment format in V2. Regards, Simon From: Brian Norris <briannor...@chromium.org> Sent: Tuesday, August 1, 2017 0:58 To: Xinming Hu Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; Z

[v2 PATCH] mwifiex: p2p: use separate device address

From: Xinming Hu <h...@marvell.com> Per below statement about p2p device address in WFA P2P spec $2.4.3: The P2P Device Address of a P2P Device shall be its globally administered MAC address, or its globally administered MAC address with the locally administered bit set. This patch follow

RE: [PATCH 01/11] mwifiex: fixup error cases in mwifiex_add_virtual_intf()

Hi, This patch serials looks fine, thanks. > -Original Message- > From: linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Brian Norris > Sent: 2017年5月13日 0:42 > To: Ganapathi Bhat; Nishant Sarmukadam > Cc: linux-ker...@vger.kernel.org;

[PATCH v3 4/6] mwifiex: usb: add timer to flush aggregation packets

From: Xinming Hu <h...@marvell.com> Aggregation will wait for next packet until limit aggr size/number reach. Packet might be drop and also packet dequeue will be stop in some cases. This patch add timer to flush packets in aggregation list to avoid long time waiting. Signed-off-by: Xinm

[PATCH v3 2/6] mwifiex: usb: kill urb before free its memory

From: Xinming Hu <h...@marvell.com> we have observed host system hang when device firmware crash, stack trace show it was an use-after-free case: previous submitted urb will be holding in usbcore, and given back to device driver when device disconnected, while the urb have been freed

[PATCH v3 6/6] mwifiex: check next packet length for usb tx aggregation

From: Xinming Hu <h...@marvell.com> The next packet length will be used by interface driver, to check if the next packet still could be aggregated. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Ganapathi Bhat <gb..

[PATCH v3 5/6] mwifiex: do not aggregate tcp ack in usb tx aggregation queue

From: Xinming Hu <h...@marvell.com> Tcp ack should be send as soon to avoid throuput drop during receive tcp traffic. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Ganapathi Bhat <gb...@marvell.com> --- v2: sam

[PATCH v3 1/6] mwifiex: use variable interface header length

From: Xinming Hu <h...@marvell.com> Usb tx aggregation feature will utilize 4-bytes bus interface header, otherwise it will be set to zero in default case. Signed-off-by: Xinming Hu <h...@marvell.com> Signed-off-by: Cathy Luo <c...@marvell.com> Signed-off-by: Ganapathi Bhat

RE: [PATCH v2 5/6] mwifiex: do not aggregate tcp ack in usb tx aggregation queue

Hi Kalle, > -Original Message- > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: 2017年5月18日 22:33 > To: Xinming Hu > Cc: Linux Wireless; Brian Norris; Dmitry Torokhov; raja...@google.com; > Zhiyuan Yang; Cathy Luo; Xinming Hu; Ganapathi Bhat > Subject: Re: [

[PATCH v4 4/5] mwifiex: usb: add timer to flush aggregation packets

From: Xinming Hu <h...@marvell.com> Aggregation will wait for next packet until limit aggr size/number reach. Packet might be drop and also packet dequeue will be stop in some cases. This patch add timer to flush packets in aggregation list to avoid long time waiting. Signed-off-by: Xinm

  1   2   >