Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

On Tue, Nov 08, 2016 at 09:29:07AM -0500, Jes Sorensen wrote: > Dave Jones writes: > > On Fri, Nov 04, 2016 at 09:56:00AM -0400, Jes Sorensen wrote: > >> > >> Joe Perches writes: > >> > On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote: > >> >> Code

[PATCH] iwlwifi: fix undefined 6000G2B firmware MAX API version

$ modinfo -F firmware iwlwifi | grep API iwlwifi-6000g2b-IWL6000G2B_UCODE_API_MAX.ucode $ modinfo -F vermagic iwlwifi 4.9.0-040900rc4-lowlatency SMP preempt mod_unload modversions Change-Id: Ie21a4be0b12b520844c1da4a8bef9e8a0097d919 Signed-off-by: TJ ---

“Wireless usage of pm-qos”

Hi, This patch from Johannes Berg removed the /dev/network_latency system, right? http://marc.info/?l=linux-wireless=144483867919159=2 So shouldn’t all the documentation be updated to indicate that it has been removed? https://wireless.wiki.kernel.org/en/developers/documentation/pm-qos

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

On Mon, Nov 07, 2016 at 08:46:41PM +0200, Kalle Valo wrote: > Xinming Hu writes: > > > We have include below change in latest submit > > https://patchwork.kernel.org/patch/9407283/ > > Please drop this patch. > > When making changes please resend the whole patchset. I do not

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

Hi, On Thu, Nov 10, 2016 at 07:57:04PM +0800, Xinming Hu wrote: > 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()

Problems getting mwifiex with sd8887 to work

Hi, I am trying to get a SD8887 based SDIO card to work with my Renesas H3 Salvator-X board. The card is either a u-blox emmy-w1-evk or a ZComax AC-180M, I am evaluating both. I really prefer to run the upstream driver instead of the paperwork protected and surprisingly old custom ones. However,

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

Dave Jones writes: > On Fri, Nov 04, 2016 at 09:56:00AM -0400, Jes Sorensen wrote: >> >> Joe Perches writes: >> > On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote: >> >> Code is 80 characters wide, and comments are /* */ never the ugly C++ >> >>

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

On 11/10/2016 12:05 AM, Johannes Berg wrote: I understand, and I understand that you/they are actually providing it when asked. However, the carl9170 project has its (entirely GPL) source tree out in the open, making it much *easier* and that was *still* thought to not be sufficient; I don't

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

Xinming Hu writes: > From: Shengzhen Li > > We may get SLEEP event from firmware even if TXDone interrupt > for last Tx packet is still pending. In this case, we may > end up accessing PCIe memory for handling TXDone after power > save handshake is

Re: cfg80211: add set/get link loss profile

"Lazar, Alexei Avshalom" writes: >>From b739abb6f29dc43a86b8b2b60e893b4441f8aa1f Mon Sep 17 00:00:00 2001 > From: Alexei Avshalom Lazar > Date: Sun, 6 Nov 2016 16:21:20 +0200 > Subject: [PATCH] cfg80211: add set/get link loss profile > >

[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 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 07/11] mwifiex: reset card->adapter during device unregister

From: Xinming Hu 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 firmware or some

[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

[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 01/11] mwifiex: check tx_hw_pending before downloading sleep confirm

From: Shengzhen Li We may get SLEEP event from firmware even if TXDone interrupt for last Tx packet is still pending. In this case, we may end up accessing PCIe memory for handling TXDone after power save handshake is completed. This causes kernel crash with external abort.

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

From: Shengzhen Li Power save handshake with firmware might be blocked by on-going data transfer. this patch check the PS status in main process and complete previous blocked PS handshake. this patch also remove redudant check before call mwifiex_check_ps_cond fuction.

cfg80211: add set/get link loss profile

>From b739abb6f29dc43a86b8b2b60e893b4441f8aa1f Mon Sep 17 00:00:00 2001 From: Alexei Avshalom Lazar Date: Sun, 6 Nov 2016 16:21:20 +0200 Subject: [PATCH] cfg80211: add set/get link loss profile Introduce NL80211_CMD_SET_LINK_LOSS_PROFILE and

RE: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card

Hi Brian, > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: Thursday, November 10, 2016 2:07 AM > To: Amitkumar Karwar > Cc: Kalle Valo; Dmitry Torokhov; linux-wireless@vger.kernel.org; Cathy > Luo; Nishant Sarmukadam; Xinming Hu > Subject: Re: [PATCH 5/5] mwifiex: wait for firmware