Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7

I created a patch which should work for 4.4.24 (at least for arch linux arm it applied successful) Just compiling the kernel... lets see what happens Did not work. First, there was a + which was wrong, guess i have this simply overseen. After fixing that i got:

Re: [PATCH v5 1/4] mwifiex: reset card->adapter during device unregister

On Thu, Oct 20, 2016 at 06:56:16PM +0530, Amitkumar Karwar wrote: > 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. >

Re: [PATCH v4 1/3] mwifiex: reset card->adapter during device unregister

Hi Amit, On Thu, Oct 20, 2016 at 01:11:31PM +, Amitkumar Karwar wrote: > > From: Brian Norris [mailto:briannor...@chromium.org] > > Sent: Tuesday, October 11, 2016 5:53 AM > > To: Amitkumar Karwar > > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam; > > raja...@google.com;

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

On Mon, Oct 24, 2016 at 07:51:32PM +0530, Amitkumar Karwar wrote: > From: Xinming Hu > > This patch ensures to wait for firmware dump completion in > mwifiex_remove_card(). > > For sdio interface, reset_trigger variable is used to identify > if mwifiex_sdio_remove() is called

Re: [PATCH 3/5] mwifiex: do not free firmware dump memory in shutdown_drv

On Mon, Oct 24, 2016 at 07:51:30PM +0530, Amitkumar Karwar wrote: > 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

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

On Mon, Oct 24, 2016 at 12:19:15PM -0700, Brian Norris wrote: > On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote: > > This variable is guarded by spinlock at all other places. This patch > > takes care of missing spinlock usage in mwifiex_shutdown_drv(). > > > > Signed-off-by:

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

Hi, On Mon, Oct 24, 2016 at 04:47:20PM -0700, Dmitry Torokhov wrote: > On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote: > > This variable is guarded by spinlock at all other places. This patch > > takes care of missing spinlock usage in mwifiex_shutdown_drv(). > > > >

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

On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote: > This variable is guarded by spinlock at all other places. This patch > takes care of missing spinlock usage in mwifiex_shutdown_drv(). > > Signed-off-by: Amitkumar Karwar > --- >

Re: [PATCH 1/2] mwifiex: fix corner case power save issue

Hi, On Fri, Oct 21, 2016 at 08:45:47PM +0530, Amitkumar Karwar wrote: > We may get SLEEP event from firmware even if TXDone 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

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

On Mon, Oct 24, 2016 at 07:51:32PM +0530, Amitkumar Karwar wrote: > From: Xinming Hu > > This patch ensures to wait for firmware dump completion in > mwifiex_remove_card(). > > For sdio interface, reset_trigger variable is used to identify > if mwifiex_sdio_remove() is called

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

On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote: > This variable is guarded by spinlock at all other places. This patch > takes care of missing spinlock usage in mwifiex_shutdown_drv(). > > Signed-off-by: Amitkumar Karwar > --- >

Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7

(please don't toppost) Did not know that this is forbidden, sorry You can find an sd-card image at https://downloads.lede-project.org/snapshots/targets/mvebu/generic/ - it won't contain any wifi drivers though, you will need to install them separately - easiest by providing internet access

[PATCH 2/3] mwifiex: Introduce mwifiex_probe_of() to parse common properties

Introduce function mwifiex_probe_of() to parse common properties. Since the interface drivers get to decide whether or not the device tree node was a valid one (depending on the compatible property), let the interface drivers pass a flag to indicate whether the device tree node was a valid one.

[PATCH 3/3] mwifiex: Enable WoWLAN for both sdio and pcie

Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt support") added WoWLAN feature only for sdio. This patch moves that code to the common module so that all the interface drivers can use it for free. It enables pcie and sdio for its use currently. Signed-off-by: Rajat Jain

[PATCH 1/3] mwifiex: Allow mwifiex early access to device structure

Today all the interface drivers (usb/pcie/sdio) assign the adapter->dev in the register_dev() callback, although they have this piece of info well before hand. This patch makes the device structure available for mwifiex right at the beginning, so that it can be used for early initialization if

[PATCH 0/3] mwifiex: Make WoWLAN a common feature

I have a Marvell card on the PCIe bus that needs to support WoWLAN (wake-on-wireless-LAN) feature. This is a feature offered by the "core" mwifiex card and is not specific to an interface (pcie/sdio/usb). Currently the code to parse the WowLAN pin, and activate it resides only in sdio.c [mostly

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

On Mon, Oct 24, 2016 at 07:51:28PM +0530, Amitkumar Karwar wrote: > This condition while calling mwifiex_check_ps_cond() is redundant. > The function internally already takes care of it. > > Signed-off-by: Amitkumar Karwar Unless you're intentionally *not* logging the

[PATCH] wireless: fix bogus maybe-uninitialized warning

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 uninitialized:

[PATCH] cw1200: fix bogus maybe-uninitialized warning

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: drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:

[PATCH] staging: rtl8192x: fix bogus maybe-uninitialized warning

The rtllib_rx_extract_addr() 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 uninitialized: drivers/staging/rtl8192e/rtllib_rx.c: In

Re: Bayesian rate control

On Sun, Oct 23, 2016 at 6:57 AM, Björn Smedman wrote: > Hi all, > > I've been thinking about rate control a bit lately. I've written up > some of my thoughts in a blog post > (http://www.openias.org/bayesian-wifi-rate-control), but very briefly It is nice to see some newer

RE: cfg80211: race problem between suspend and disconnect event

Hi Johannes, > From: Johannes Berg [mailto:johan...@sipsolutions.net] > Sent: Saturday, October 22, 2016 2:54 AM > To: Amitkumar Karwar > Cc: Kalle Valo; Brian Norris; Nishant Sarmukadam; Cathy Luo; linux- > wirel...@vger.kernel.org; Ganapathi Bhat > Subject: Re: cfg80211: race problem between

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On Monday, October 24, 2016 4:38:36 PM CEST Johannes Berg wrote: > On Mon, 2016-10-24 at 16:36 +0200, Simon Wunderlich wrote: > > On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote: > > > On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote: > > > > Otherwise, it would be pretty

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On Mon, 2016-10-24 at 16:36 +0200, Simon Wunderlich wrote: > On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote: > > > > On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote: > > > > > > Otherwise, it would be pretty much impossible to perform CSAs to > > > another DFS channel.

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote: > On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote: > > Otherwise, it would be pretty much impossible to perform CSAs to > > another DFS channel. > > I was told that to do that you'd need another NIC that's pre-CAC'ing >

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

This variable is guarded by spinlock at all other places. This patch takes care of missing spinlock usage in mwifiex_shutdown_drv(). Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/marvell/mwifiex/init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 4/5] mwifiex: firmware dump code rearrangement in pcie.c

From: Xinming Hu The next patch will refer to pcie_work in mwifiex_pcie_remove function. This patch puts pcie_work related functions ahead to mwifiex_pcie_remove to avoid static forward declaration. Signed-off-by: Xinming Hu Signed-off-by: Amitkumar Karwar

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote: > Otherwise, it would be pretty much impossible to perform CSAs to > another DFS channel. I was told that to do that you'd need another NIC that's pre-CAC'ing another channel. johannes

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

From: Xinming Hu This patch ensures to wait for firmware dump completion in mwifiex_remove_card(). For sdio interface, reset_trigger variable is used to identify if mwifiex_sdio_remove() is called by sdio_work during reset or the call is from sdio subsystem. This patch fixes

[PATCH 3/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 ---

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

This condition while calling mwifiex_check_ps_cond() is redundant. The function internally already takes care of it. Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/marvell/mwifiex/main.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

RE: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.

OK . Thanks . We shall wait for them to get up streamed. Regards, Sunil -Original Message- From: Johannes Berg [mailto:johan...@sipsolutions.net] Sent: Monday, October 24, 2016 7:06 PM To: Undekari, Sunil Dutt ; Kushwaha, Purushottam

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On 24 October 2016 at 15:42, Simon Wunderlich wrote: > On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote: >> > > I think it would be reasonable only if the target channel is the >> > > one we are using and we have done CSA. But when scanning non- >> > >

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote: > > > I think it would be reasonable only if the target channel is the > > > one we are using and we have done CSA. But when scanning non- > > > operative channels I don't think this could work. > > > > this has been sleeping for a

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

On Mon, Oct 24, 2016 at 03:33:24PM +0200, Johannes Berg wrote: > > > > I think it would be reasonable only if the target channel is the > > > one we are using and we have done CSA. But when scanning non- > > > operative channels I don't think this could work. > > > this has been sleeping for a

Re: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.

On Mon, 2016-10-24 at 11:59 +, Undekari, Sunil Dutt wrote: > > > > I've just sent out a few patches that, I think, implement the > > necessary validation for just the beacon intervals, without all > > this extra baggage. Please take a look and let me know what you > > think. > I understand

Re[2]: compex wle900vx (ath10k) problem on 4.4.24 / armv7

I (naively) went through pci/pm git log and found the following was applied on 4.7-rc2 (i.e. prior to 4.7 release): commit 006d44e49a259b39947366728d65a873a19aadc0 Author: Mika Westerberg Date: Thu Jun 2 11:17:15 2016 +0300 PCI: Add runtime PM

RE: [PATCH v3] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.

> I've just sent out a few patches that, I think, implement the necessary > validation for just the beacon intervals, without all this extra baggage. > Please take a look and let me know what you think. I understand that the new patches from you are in consistent with the existing design of

Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7

On 24 October 2016 at 12:18, Matthias Klein wrote: > I also try to get a pcie wifi card (Compex WLE600VX) running in the clearfog > pro board with kernel 4.4. > > As I read in this thread the "irg.mode=1" shoud help: >

Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7

Hi, (please don't toppost) On 23 October 2016 at 21:42, Oliver Zemann wrote: > Thanks, but its still not working. I dont get any error now when i do > modprobe and installed is the wle900 > > [root@alarm alarm]# rmmod ath10k_pci > [root@alarm alarm]# modprobe ath10k_pci

Re: compex wle900vx (ath10k) problem on 4.4.24 / armv7

I also try to get a pcie wifi card (Compex WLE600VX) running in the clearfog pro board with kernel 4.4. As I read in this thread the "irg.mode=1" shoud help: https://www.spinics.net/lists/linux-wireless/msg155685.html But it is not working for me: debian@clearfog:~$ lsmod Module Size Used

[mac80211-next:genl 9/9] net/wireless/nl80211.c:8469:63: error: expected ',' or ';' before ')' token

tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl head: 09566d222ce4d6aab069c8b7dc625675c6cca3fc commit: 09566d222ce4d6aab069c8b7dc625675c6cca3fc [9/9] genetlink: introduce and use genl_family_attrbuf() config: i386-randconfig-c0-10241534 (attached as

[mac80211-next:genl 5/9] net/netlink/genetlink.c:430:1: warning: label 'errout' defined but not used

tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl head: fc4c3f9724b5c4b730490ce2637369fee6e8b87b commit: dcc56960c6e6fa10b50d5433b10fc216a3f7c996 [5/9] genetlink: no longer support using static family IDs config: i386-randconfig-x004-201643 (attached as

[mac80211-next:genl 2/2] net/netlink/genetlink.c:693:9: error: 'genl_ctrl_ops' undeclared here (not in a function)

tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git genl head: e406d0fb91172c4dc5364b4a2228679cb07e512c commit: e406d0fb91172c4dc5364b4a2228679cb07e512c [2/2] genetlink: statically initialize families config: i386-randconfig-x004-201643 (attached as .config)