Re: [PATCH V3] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

> > > +static int qtnf_pcie_init_shm_ipc(struct qtnf_pcie_bus_priv > > > *priv) > > > +{ > > > + struct qtnf_shm_ipc_region __iomem *ipc_tx_reg; > > > + struct qtnf_shm_ipc_region __iomem *ipc_rx_reg; > > > + const struct qtnf_shm_ipc_int ipc_int = { > > qtnf_ipc_gen_ep_int, priv }; > > > > > >

Re: [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang

On Mittwoch, 16. November 2016 16:16:42 CET Valo, Kalle wrote: > Sven Eckelmann writes: > > > From: Simon Wunderlich > > > > QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a state in > > which a read of AR_CFG

Re: [net-next] rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb

Wei Yongjun wrote: > From: Wei Yongjun > > It is not allowed to call kfree_skb() from hardware interrupt > context or with interrupts being disabled, spin_lock_irqsave() > make sure always in irq disable context. So the kfree_skb() > should be

Re: ssb: Fix error routine when fallback SPROM fails

Larry Finger wrote: > When there is a CRC error in the SPROM read from the device, the code > attempts to handle a fallback SPROM. When this also fails, the driver > returns zero rather than an error code. > > Signed-off-by: Larry Finger >

Re: [v2] cw1200: fix bogus maybe-uninitialized warning

Arnd Bergmann wrote: > On x86, the cw1200 driver produces a rather silly warning about the > possible use of the 'ret' variable without an initialization > presumably after being confused by the architecture specific definition > of WARN_ON: > >

Re: wireless: fix bogus maybe-uninitialized warning

Arnd Bergmann wrote: > The hostap_80211_rx() function is supposed to set up the mac addresses > for four possible cases, based on two bits of input data. For > some reason, gcc decides that it's possible that none of the these > four cases apply and the addresses remain

Re: p54: memset(0) whole array

Jiri Slaby wrote: > gcc 7 complains: > drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan': > drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with > length equal to number of elements without multiplication by element size >

Re: brcmfmac: print name of connect status event

Rafał Miłecki wrote: > From: Rafał Miłecki > > This simplifies debugging. Format %s (%u) comes from similar debugging > message in brcmf_fweh_event_worker. > > Signed-off-by: Rafał Miłecki Patch applied to wireless-drivers-next.git, thanks. e1c122d55f9e

Re: [1/3] rsi: Fix memory leak in module unload

Prameela Rani Garnepudi wrote: > Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set. > Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in > function rsi_mac80211_detach() > Memory leak found and fixed for below

Re: wlcore: Allow scans when in AP mode

Xander Huff wrote: > From: James Minor > > When in AP mode, scans can be done without changing firmware to > the multi-role firmware. Allow the interface to scan if forced > in the scan request. > > Signed-off-by: James Minor >

Re: [1/8] rtlwifi: rtl8192de: Remove address of Free Software Foundation

Larry Finger wrote: > Since this driver was added to the kernel, the checkpatch script was > modified to request that the address of the FSF not be included. > > Signed-off-by: Larry Finger 8 patches applied to wireless-drivers-next.git,

Re: [v3] mwifiex: report wakeup for wowlan

Rajat Jain wrote: > Register the WLAN device as a wakeup source since it can > wake the system via wake-on-wireless-lan. In an actual wowlan > event, notify the PM core that we are the current wakeup source. > This allows the PM core to update the wakeup attributes in /sys. >

[PATCH] RFC: Universal scan proposal

From 68a9d37a4c7e9dc7a90a6e922cdea52737a98d66 Mon Sep 17 00:00:00 2001 From: Dmitry Shmidt Date: Wed, 16 Nov 2016 14:27:26 -0800 Subject: [PATCH] RFC: Universal scan proposal Currently we have sched scan with possibility of various intervals. We would like to extend it

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

John Heenan writes: > Barry Day has submitted real world reports for the 8192eu and 8192cu. > This needs to be acknowledged. I have submitted real world reports for > the 8723bu. Lets get this a little more clear - first of all, I have asked you to investigate which part resolves

Re: [PATCH v3 4/5] mwifiex: wait firmware dump complete during card remove process

On Wed, Nov 16, 2016 at 06:39:08PM +0530, Amitkumar Karwar wrote: > From: Xinming Hu > > Wait for firmware dump complete in card remove function. > For sdio interface, there are two diffenrent cases, > card reset trigger sdio_work and firmware dump trigger sdio_work. > Do code

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

On Wed, Nov 16, 2016 at 01:07:31PM +, Amitkumar Karwar wrote: > I observed some crash issues while testing with PCIe/SDIO chipsets > after removing user_rmmod. We are still checking them. I will not > include user_rmmod removal patch in v3 series. Other pcie_work related > global variables are

Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()

Bjorn Andersson wrote: > The correct include file for getting errno constants and ERR_PTR() is > linux/err.h, rather than linux/errno.h, so fix the include. > > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled > smem_state") > Acked-by: Andy Gross

Re: [PATCH V3] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

Resending because previous attempt was rejected by vger.kernel.org On 11/16/2016 06:04 PM, IgorMitsyanko wrote: On 11/14/2016 12:52 PM, Johannes Berg wrote: +++ b/drivers/net/wireless/quantenna/qtnfmac/Kconfig @@ -0,0 +1,23 @@ +config QTNFMAC + tristate "Quantenna WiFi FullMAC WLAN

Re: [PATCH V3] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

On 11/15/2016 12:06 PM, Johannes Berg wrote: On Wed, 2016-11-09 at 17:00 +0300, igor.mitsyanko...@quantenna.com wrote: +static int +qtnf_change_virtual_intf(struct wiphy *wiphy, +struct net_device *dev, +enum nl80211_iftype type, u32 *flags, +

Re: [PATCH] rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB

On Wed, Nov 16, 2016 at 05:01:54PM +0100, Vishal Thanki wrote: > In device removal routine, usage of "#ifdef CONFIG_RT2X00_LIB_USB" > will not cover the case when it is configured as module. This will > omit the entire if-block which does cleanup of URBs and cancellation > of pending work.

Re: [RFC 1/2] ath9k: work around AR_CFG 0xdeadbeef chip hang

Sven Eckelmann writes: > From: Simon Wunderlich > > QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a state in > which a read of AR_CFG always returns 0xdeadbeef. This should not happen > when when the power_mode of

Re: [PATCH] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success

Matthias Schiffer writes: > On 11/16/2016 03:08 PM, Kalle Valo wrote: >> Matthias Schiffer writes: >> >>> Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and >>> SOC") refactored ath9k_hw_gpio_get() to support

Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor

2016-11-16 13:02 GMT+01:00 Stanislaw Gruszka : > On Wed, Nov 16, 2016 at 09:07:00AM +0100, Mathias Kresin wrote: >> Here are the results of the requested tests. Please keep in mind, I'm not in >> a lab environment: >> >> LEDE head >> connect >> action 0 sta

RE: [PATCH v2 5/5] mwifiex: wait firmware dump complete during card remove process

Hi Brian, > > + > > static int > > mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct > sk_buff *skb, > >size_t size, int flags) > > @@ -249,6 +252,8 @@ static void mwifiex_pcie_remove(struct pci_dev > *pdev) > > if (!adapter || !adapter->priv_num) > >

[PATCH] staging: wilc1000: simplify vif[i]->ndev accesses

With gcc-7, I got a new warning for this driver: wilc1000/linux_wlan.c: In function 'wilc_netdev_cleanup': wilc1000/linux_wlan.c:1224:15: error: 'vif[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized] wilc1000/linux_wlan.c:1224:15: error: 'vif[0]' may be used

Re: [RFC 03/12] ath10k: htc: Changed order of wait target and ep connect

On 15 November 2016 at 18:07, Erik Stromdahl wrote: > On 11/15/2016 11:13 AM, Michal Kazior wrote: >> On 14 November 2016 at 17:33, Erik Stromdahl >> wrote: >>> This patch changes the order in which the driver waits for the >>> target to

Re: [PATCH] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success

Matthias Schiffer writes: > Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and > SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs, > changing the return on success from 1 to BIT(gpio). This broke some callers > like

Re: [PATCH] brcmfmac: update beacon IE when bss up and clear when stopped

Wright Feng writes: > Firmware doesn't update beacon vendor IEs when bss is down, so move > brcmf_config_ap_mgmt_ie after BSS up. And host driver should clear IEs when > AP stopped so that the IEs in host side will be synced with in firmware side. > > Signed-off-by: Wright

Re: [05/10] rt2800: make ba_size depend on ampdu_factor

Stanislaw Gruszka wrote: > We can calculate BA window size (max number of pending frames not > yet block acked) of remote station using Maximum A-MPDU length factor > for that station. > > Signed-off-by: Stanislaw Gruszka Dropping as requested by

Re: [RFC 02/12] ath10k: htc: rx trailer lookahead support

Erik Stromdahl writes: > On 11/15/2016 10:57 AM, Michal Kazior wrote: >> On 14 November 2016 at 17:33, Erik Stromdahl >> wrote: >>> The RX trailer parsing is now capable of parsing lookahead reports. >>> This is needed by SDIO/mbox. >> >>

[PATCH v3 5/5] mwifiex: move pcie_work and related variables inside card

From: Ganapathi Bhat Currently pcie_work and related variables are global. It may create problem while supporting multiple devices simultaneously. Let's move it inside card structure so that separate instance will be created/ cancelled in init/teardown threads of each

[PATCH v3 3/5] mwifiex: get rid of drv_info* adapter variables

From: Xinming Hu We can avoid drv_info_dump and drv_info_size adapter variables. This info can be passed to mwifiex_upload_device_dump() as parameters Signed-off-by: Xinming Hu Signed-off-by: Amitkumar Karwar --- v2: This patch is

[PATCH v3 4/5] mwifiex: wait firmware dump complete during card remove process

From: Xinming Hu Wait for firmware dump complete in card remove function. For sdio interface, there are two diffenrent cases, card reset trigger sdio_work and firmware dump trigger sdio_work. Do code rearrangement for distinguish between these two cases. Signed-off-by: Xinming

[PATCH v3 2/5] mwifiex: do not free firmware dump memory in shutdown_drv

From: Xinming Hu mwifiex_upload_device_dump() already takes care of freeing firmware dump memory. Doing the same thing in mwifiex_shutdown_drv() is redundant. Signed-off-by: Xinming Hu Signed-off-by: Amitkumar Karwar --- v2: Same as v1.

[PATCH v3 1/5] mwifiex: don't wait for main_process in shutdown_drv

From: Xinming Hu main_process is not expected to be running when shutdown_drv function is called. currently we wait for main_process completion in the function. Actually the caller has already made sure main_process is completed by performing below actions. (1) disable

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

Hi Brian, > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: Friday, November 11, 2016 1:17 AM > To: Kalle Valo > Cc: Xinming Hu; Amitkumar Karwar; linux-wireless@vger.kernel.org; Cathy > Luo; Nishant Sarmukadam; raja...@google.com; dmitry.torok...@gmail.com > Subject: Re: [PATCH v2

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

Re: [PATCH 0/8] iw: Add common chandef parser and new DFS related commands

On Mon, 2016-11-07 at 15:59 +0100, Benjamin Berg wrote: > From: Benjamin Berg > > Hi, > > This patchset adds commands for doing a CAC and sending CSA. > > Another change is that parsing of command line frequency and channel > definitions is split out so that it can

Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor

On Wed, Nov 16, 2016 at 09:07:00AM +0100, Mathias Kresin wrote: > Here are the results of the requested tests. Please keep in mind, I'm not in > a lab environment: > > LEDE head > connect > action 0 sta 9c:f3:87:bc:AA:BB tid 6 buf_size 64 ampdu_factor 3 > action 2 sta 9c:f3:87:bc:AA:BB

[PATCH v2 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE

We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on rt2800_init_registers() for USB devices. For PCI devices we will use HW default setting, which is 2, so patch does not change behaviour on PCI devices. Signed-off-by: Stanislaw Gruszka --- v1 -> v2 Changelog fixes

Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value

On 15-11-2016 12:10, Kalle Valo wrote: > Gianfranco Costamagna writes: > >>> Well, not before you pointed it out ;-). You are welcome to send a patch >>> fixing it. Otherwise, I will take care of it. >> >> attaching a format-patch like version. >> I don't think we need

[PATCH] ath9k: fix NULL pointer dereference

From: Miaoqing Pan relay_open() may return NULL, check the return value to avoid the crash. BUG: unable to handle kernel NULL pointer dereference at 0040 IP: [] ath_cmn_process_fft+0xd5/0x700 [ath9k_common] PGD 41cf28067 PUD 41be92067 PMD 0 Oops: [#1]

RE: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption

Hey Adrian, Sounds like an idea, although up to this point I have not been able to detect whether replumbing is necessary. decrypt_errors does not increment exponentially on the receive path, as far as I saw only one decrypt_error comes through, which could just as well be a corrupted frame. I

Re: [PATCH 04/10] rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE

14.11.2016 09:42, Stanislaw Gruszka: On Sat, Nov 05, 2016 at 01:55:14PM +0100, Mathias Kresin wrote: 02.11.2016 15:10, Stanislaw Gruszka: We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on rt2800_init_registers(). Signed-off-by: Stanislaw Gruszka ---

Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor

14.11.2016 13:43, Stanislaw Gruszka: On Mon, Nov 14, 2016 at 09:45:36AM +0100, Stanislaw Gruszka wrote: Could you check below patch and see if it helps? If it does not, could you printk sta->ht_cap.ampdu_density and ba_size values and provide them here. Actually please print parameters from