Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 17 June 2016 at 07:13, Kalle Valo wrote: > Rafał Miłecki writes: > >> On 16 June 2016 at 17:10, Kalle Valo wrote: >>> Rafał Miłecki writes: >>> Removing P2P interface is handled by sending a proper request

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

Rafał Miłecki writes: > On 16 June 2016 at 17:10, Kalle Valo wrote: >> Rafał Miłecki writes: >> >>> Removing P2P interface is handled by sending a proper request to the >>> firmware. On success firmware triggers an event and driver's

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 16 June 2016 at 17:10, Kalle Valo wrote: > Rafał Miłecki writes: > >> Removing P2P interface is handled by sending a proper request to the >> firmware. On success firmware triggers an event and driver's handler >> removes a matching interface. >> >>

RE: rt2800usb firmware rt2870.bin 0.36 not scanning

I wrote: > I wrote: > > Xose Vazquez Perez wrote: > > > Craig McQueen wrote: > > > > > > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based > > > > (5392 chipset). I'm trying to use it on a BeagleBone Black based > > > > system with 3.14.x kernel built with Yocto. We're using ConnMan

[PATCH] ath9k: return false when reading wrong eeprom offset

Just setting the proper return for reading beyond the eeprom data. Signed-off-by: Eduardo Abinader --- drivers/net/wireless/ath/ath9k/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/pci.c

[PATCH v2] ath10k: Fix some typo in spectral code commments

From: Mohammed Shafi Shajakhan Found this obvious typo while going through the spectral code design in ath10k Signed-off-by: Mohammed Shafi Shajakhan --- drivers/net/wireless/ath/ath10k/spectral.c | 4 ++-- 1 file changed, 2 insertions(+),

Re: Intel wifi card + TP-LINK AC1200 rev 1.2 = ???

Apparently, this was still in my drafts. Sorry for the delay. I've been away from home for a couple of weeks, today I'm home for one day, so I've made the files you suggested. On 05/24/2016 07:52 AM, Luca Coelho wrote: > This sounds like an interoperability issue between your AP (AC1200) and >

Re: [v3,1/2] b43: Remove unused phy_a code

On Thu, 16 Jun 2016 18:56:14 +0300 Kalle Valo wrote: > Michael Büsch writes: > > > On Thu, 16 Jun 2016 15:23:37 + (UTC) > > Kalle Valo wrote: > > > >> Guenter Roeck wrote: > >> > gcc-6 reports the following

Re: [PATCH] rtlwifi: use s8 instead of char

David Laight writes: > From: Arnd Bergmann >> On Wednesday, June 15, 2016 5:10:51 PM CEST Jes Sorensen wrote: >> > >> > Arnd, >> > >> > rtlwifi and rtl8xxxu are two distinct drivers managed by different >> > people. I'd be really nice if you could split this into a per

RE: [PATCH] ath10k: Fix a typo in spectral code commments

+ linux wireless, ath10k Thanks, initially I could not get what you meant :( -Original Message- From: Arthur Jagiella [mailto:jagie...@vitracom.de] Sent: Tuesday, June 14, 2016 2:06 PM To: Shajakhan, Mohammed Shafi (Mohammed Shafi) Subject: Re: [PATCH]

Re: [PATCH] ath9k: return false when reading wrong eeprom offset

Eduardo Abinader writes: > Just setting the proper return for reading beyond the > eeprom data. > > Signed-off-by: Eduardo Abinader > --- > drivers/net/wireless/ath/ath9k/pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff

RE: [PATCH] rtlwifi: use s8 instead of char

From: Arnd Bergmann > On Wednesday, June 15, 2016 5:10:51 PM CEST Jes Sorensen wrote: > > > > Arnd, > > > > rtlwifi and rtl8xxxu are two distinct drivers managed by different > > people. I'd be really nice if you could split this into a per driver > > patch. > > > > That said, the use of char in

Re: [PATCH] ath10k: Fix a typo in spectral code commments

On Thu, Jun 16, 2016 at 11:59:59AM -0400, Bob Copeland wrote: > On Tue, Jun 14, 2016 at 11:03:54AM +0530, Mohammed Shafi Shajakhan wrote: > > From: Mohammed Shafi Shajakhan > > > > Found this obvious typo while going through the spectral > > code design in ath10k > >

Re: [PATCH] ath10k: Fix a typo in spectral code commments

On Tue, Jun 14, 2016 at 11:03:54AM +0530, Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Found this obvious typo while going through the spectral > code design in ath10k > /* TODO: As experiments with an analogue sender and various

Re: [v3,1/2] b43: Remove unused phy_a code

Michael Büsch writes: > On Thu, 16 Jun 2016 15:23:37 + (UTC) > Kalle Valo wrote: > >> Guenter Roeck wrote: >> > gcc-6 reports the following error with -Werror=unused-const-variable. >> > >> >

Re: [v3,1/2] b43: Remove unused phy_a code

On Thu, 16 Jun 2016 15:23:37 + (UTC) Kalle Valo wrote: > Guenter Roeck wrote: > > gcc-6 reports the following error with -Werror=unused-const-variable. > > > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > > 'b43_phyops_a' defined

Re: ATH9K warnings from commit b2d70d494

John S Gruber writes: > It's an AR9462 > > Here's the wifi adapter: > > 03:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter > (rev 01) > Subsystem: Lite-On Communications Inc Device 6621 > Flags: bus master, fast devsel, latency 0, IRQ 19 > Memory

Re: libertas: Remove create_workqueue

Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > In if_sdio.c, the workqueue card->workqueue has workitem > >packet_worker, which is mapped to if_sdio_host_to_card_worker. > The workitem is involved in sending packets to firmware.

Re: brcmfmac: include required headers in cfg80211.h

Rafał Miłecki wrote: > Without this including cfg80211.h in a wrong order could result in: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:122:24: error: > array type has incomplete element type > struct brcmf_wsec_key key[BRCMF_MAX_DEFAULT_KEYS]; > ^ >

Re: [v3,1/2] b43: Remove unused phy_a code

Guenter Roeck wrote: > gcc-6 reports the following error with -Werror=unused-const-variable. > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > 'b43_phyops_a' defined but not used > > Per Michael Büsch: "All a-phy code is usused", so remove it all, > and

Re: brcmfmac: drop unused pm_block vif attribute

Rafał Miłecki wrote: > This attribute was added 3 years ago by > commit 3eacf866559c ("brcmfmac: introduce brcmf_cfg80211_vif structure") > but it remains unused since then. It seems we can safely drop it. > > Signed-off-by: Rafał Miłecki Thanks, 1 patch applied to

Re: [1/6] brcmfmac: fix skb priority handling

Arend Van Spriel wrote: > From: Hante Meuleman > > SKBs can come with a prioriy. Currently a priority of 0..7 is > assumed. But this assumption is incorrect. To fix this any > priority of 0 or higher then 7 will be adjusted by calling >

Re: [V2, next] brcmfmac: don't remove interface on link down firmware event

Rafał Miłecki wrote: > There are two firmware events we handle similarly in brcmfmac: > BRCMF_E_LINK and BRCMF_E_IF. The difference from firmware point of view > is that the first one means BSS remains present in the firmware. Trying > to (re)create it (e.g. when adding new virtual interface) will

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

Rafał Miłecki writes: > Removing P2P interface is handled by sending a proper request to the > firmware. On success firmware triggers an event and driver's handler > removes a matching interface. > > However on event timeout we remove interface directly from the cfg80211 >

Re: [V2] brcmfmac: fix setting AP channel with new firmwares

Rafał Miłecki wrote: > Firmware for new chipsets is based on a new major version of code > internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for > BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was > based on 7.35.177.56. > > Currently setting AP 5 GHz

Re: [V6] brcmfmac: print errors if creating interface fails

Arend van Spriel wrote: > From: Rafał Miłecki > > This is helpful for debugging. Without this all I was getting from "iw" > command on failed creating of P2P interface was: > > command failed: Too many open files in system (-23) > > Signed-off-by: Rafal

Re: [PATCH v2] mwifiex: fix race condition when downloading firmware

Wei-Ning Huang writes: > The action 'check for winner' and 'download firmware' should be an > atomic action. This is true for btmrvl driver but not mwmfiex, which > cause firmware download to fail when the following scenario happens: > > 1) mwifiex check winner status: true

Re: wl3501_cs: avoid bogus gcc-6 warning

Arnd Bergmann wrote: > gcc-6 on x86 started warning about wl3501_get_encode when building > with -O2: > > drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_get_encode’: > drivers/net/wireless/wl3501_cs.c:1769:5: warning: ‘implemented’ may be used > uninitialized in this

Re: [1/8] mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node

Javier Martinez Canillas wrote: > SDIO is an auto enumerable bus so the SDIO devices are matched using the > sdio_device_id table and not using compatible strings from a OF id table. > > However, commit ce4f6f0c353b ("mwifiex: add platform specific wakeup > interrupt

Re: [4/4] rtl8xxxu: fix typo on variable name, compare against correct variable

Jes Sorensen wrote: > From: Colin Ian King > > path_b_ok is being assigned but immediately after path_a_ok is being > compared to the value 0x03. This appears to be a typo on the > variable name, compare path_b_ok instead. > > Signed-off-by:

Re: [PATCH] ath10k: add support for controlling tx power to a station

kbuild test robot writes: > [auto build test ERROR on ath6kl/ath-next] > [also build test ERROR on v4.7-rc3 next-20160614] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

[PATCH 0/8] net: fix old-style declarations

"make W=1" enables -Wold-style-declaration, which is generally useful to warn about pre-C89 code in the kernel, but it also warns about some harmless variations (sometimes many of them from a single file). This fixes up the 8 instances I found in the networking code, there is another series of 12

[PATCH 2/8] wireless: brcmsmac: fix old-style declaration

Modern C standards expect the 'static' keyword to come first in a declaration, and we get a warning for this with "make W=1": drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:3353:1: error: 'static' is not at beginning of declaration [-Werror=old-style-declaration] Signed-off-by: Arnd

[PATCH 6/6] mwifiex: fix AP start problem for newly added interface

It's been observed that if interface type is changed from managed to __ap, AP can be successfully started. But there is a problem if new ap interface is added. The problem got resolved after sending appropriate commands to firmware in add_interface handler. Signed-off-by: Amitkumar Karwar

[PATCH 5/6] mwifiex: fix AP unable to start in VHT40 problem

This patch populates secondary channel offset and downloads it to firmware to fix the problem. Signed-off-by: Amitkumar Karwar Signed-off-by: Cathy Luo --- drivers/net/wireless/marvell/mwifiex/ioctl.h | 2 ++

[PATCH 4/6] mwifiex: fix system hang problem after resume

On some platforms, driver is unable to wakeup firmware after system resume due to a problem at MMC subsystem. Triggering card reset in this case has a race with card removal from MMC which causes system hang. This patch resolves the problem by not triggering card reset. Signed-off-by: Amitkumar

[PATCH 3/6] mwifiex: cancel pending scan during disconnect

From: Xinming Hu It is obeserved that sometimes scan operation will block the disconnect during system suspend. It's ok to cancel ongoing scan in this case. It reduces unnecessary system suspend delay. Signed-off-by: Xinming Hu Signed-off-by: Amitkumar

[PATCH 2/6] mwifiex: factor out mwifiex_cancel_scan

From: Xinming Hu This patch creates common function mwifiex_cancel_scan to remove duplication of code. Signed-off-by: Xinming Hu Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/marvell/mwifiex/cmdevt.c | 40

[PATCH 1/6] mwifiex: Fix an issue spotted by KASAN

From: Ganapathi Bhat When an association command is sent to firmware but the process is killed before the command response arrives, driver will try to access bss_desc which is already freed. This issue is fixed by checking return value of bss_start. Signed-off-by: Amitkumar

[PATCH] ath10k: Disable TX_STBC for tx chainmask of 1

From: Mohammed Shafi Shajakhan Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1' TX_STBC is required only for devices with tx_chainmask > 1. This fixes a ping failure for QCA9887 (1x1) in HT/VHT mode Signed-off-by: Mohammed Shafi Shajakhan

[PATCH] ath10k: Enable beacon loss detection support for 10.4

From: Mohammed Shafi Shajakhan Enable beacon loss detection support for 10.4 by handling roam event. With this change QCA99X0 station is able to detect beacon loss when the AP is powered off Signed-off-by: Mohammed Shafi Shajakhan ---

Re: Getting signal strength of a received packets

Hi thank you very much for quick reply, and parser. I can do by your proposed way, but if I can use an API to get it directly from kernel that would make our work more organized and faster. On Thu, Jun 16, 2016 at 2:51 PM, Rafał Miłecki wrote: > On 16 June 2016 at 12:10, Majid

Re: Problems with mwifiex_pcie firmware activation

Hi On Wed, Jun 15, 2016 at 01:47:53PM +, Amitkumar Karwar wrote: > Could you please share complete dmesg log for failure and successful cases? Dmesg from failure case is in attachment. I loose access to system where device initalize, I'll provide missed dmesg when I get back the access. >

Re: [wireless-drivers-next:master 13/19] main.c:undefined reference to `sdio_claim_host'

Wei-Ning Huang writes: > Hi Kalle, Please send mails to the list, not to me privately > This patch is replaced by a new version: https://patchwork.kernel.org/patch/ > 9138245/ > and should build fine. [...] > tree:   

Re: ATH9K warnings from commit b2d70d494

(Adding linux-wireless) johnsgru...@gmail.com writes: > I'm getting many warning stack traces fom the above--at least two every 5 > seconds whether or not connected via wireless. > > Samples are below. > > On further investigation I see that for each of the pair gpio = 11, for > the first

Re: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support

Mohammed Shafi Shajakhan writes: >> Also please ping instead of resending patches. These are already waiting >> in patchwork: >> >> https://patchwork.kernel.org/patch/8993601/ >> https://patchwork.kernel.org/patch/8993621/ > > [shafi] oh ok thanks, sorry i thought this

Re: Getting signal strength of a received packets

On 16 June 2016 at 12:10, Majid Ashoori wrote: > Hi everyone, > I am using OCB mode based on ath9k driver for my wireless connections > between different nodes. In this mode there is no BS or established > connection to analyze the signal strength of BS. Thus, I need to know >

Getting signal strength of a received packets

Hi everyone, I am using OCB mode based on ath9k driver for my wireless connections between different nodes. In this mode there is no BS or established connection to analyze the signal strength of BS. Thus, I need to know the signal strength of received packets in my user-space application to do

[PATCH v4 2/2] mmc: sdio support external scatter gather list

From: Xinming Hu Currently sdio device drivers need to prepare a big continuous physical memory for large data transfer. mmc stack will construct scatter/gather buffer list to make use of ADMA2. According to the sdio host controller specification version 4.00 chapter 1.13.2,

[PATCH v4 1/2] mmc: API for accessing host supported maximum segment count and size

From: Xinming Hu sdio device drivers need be able to get the host supported max_segs and max_seg_size, so that they know the buffer size to allocate while utilizing the scatter/gather DMA buffer list. This patch provides API for this purpose. Signed-off-by: Xinming Hu

[PATCH] mwifiex: fix link error against sdio

Calling sdio_claim_host() from the interface independent part of the mwifiex driver is not only a layering violation, but also causes a link error if MMC support is disabled, or if CONFIG_MMC=m and CONFIG_MWIFIEX=y: drivers/net/built-in.o: In function `mwifiex_fw_dpc': :(.text+0xff138): undefined