Re: ath10k firmware crashes in mesh mode on QCA9880

Hi, On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote: > When we try to transmit traffic (ping) between two meshed ath10k > devices running latest lede we keep experiencing ath10k firmware > crashes. This seems to only happen when running in 802.11n/ac mode > but not in 802.11a/g

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

Hi Adrian, On Wed, Nov 30, 2016 at 10:27:25AM -0800, Adrian Chadd wrote: > Heh, I had to do something like this for freebsd too for my ath10k > port. So thanks. :) [shafi] thanks :):) > > Suggestion - take a look at where tasklets, completions, locks, etc > are all re-allocated multiple times,

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote: > Is this something for stable? And if so, how far back should it be applied? @Kalle, [shafi] kindly suggest. If i am not wrong this is only needed for 4.9 > > I'll add this patch to my 4.9 tree and test it... > [shafi] thanks a lot

Re: pull-request: wireless-drivers 2016-11-29

David Miller writes: > From: Kalle Valo > Date: Tue, 29 Nov 2016 16:59:44 +0200 > >> if there's still time here's one more patch to 3.9. I think this is good >> to have in 3.9 as it fixes an issue where we were printing uninitialised >> memory in

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

Kalle Valo writes: > "Valo, Kalle" writes: > >> Bjorn Andersson writes: >> >>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote: >>> Bjorn Andersson wrote: > The correct include

Package has been sent.

Your shipment(s) is scheduled for delivery Scheduled Delivery Date: 12/02/2016 Shipper: Chambers Group. Kindly view the attached document for shipment/delivery details and tracking procedure. You can also request a delivery change (e.g. reschedule or reroute) from the tracking detail.

[PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization

mesh_sync_offset_adjust_tbtt() implements Extensible synchronization framework ([1] 13.13.2 Extensible synchronization framework). It shall not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon collision avoidance,

Re: pull-request: wireless-drivers 2016-11-29

From: Kalle Valo Date: Tue, 29 Nov 2016 16:59:44 +0200 > if there's still time here's one more patch to 3.9. I think this is good > to have in 3.9 as it fixes an issue where we were printing uninitialised > memory in mwifiex. I had this in wireless-drivers already for some

[patch] mwifiex: clean up some messy indenting

These lines were indented one tab extra. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c index f5dffdf..fdc6cc2 100644 --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c +++

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

"Valo, Kalle" writes: > Bjorn Andersson writes: > >> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote: >> >>> Bjorn Andersson wrote: >>> > The correct include file for getting errno constants and ERR_PTR() is >>> >

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

Heh, I had to do something like this for freebsd too for my ath10k port. So thanks. :) Suggestion - take a look at where tasklets, completions, locks, etc are all re-allocated multiple times, once upon initial VAP bringup. I had to also undo this in FreeBSD, as we don't allow re-init of tasks,

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

Kalle Valo writes: > Jes Sorensen writes: > >> Luca Coelho writes: >>> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote: jes.soren...@redhat.com writes: > From: Jes Sorensen >

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

Jes Sorensen writes: > Luca Coelho writes: >> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote: >>> jes.soren...@redhat.com writes: >>> >>> > From: Jes Sorensen >>> > >>> > Hi, >>> > >>> > This patch works around the issue

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

Luca Coelho writes: > On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote: >> jes.soren...@redhat.com writes: >> >> > From: Jes Sorensen >> > >> > Hi, >> > >> > This patch works around the issue with 8192eu and 8723bu devices not >> > being able to

[PATCH 1/2] mwifiex: code rearrangement in pcie.c and sdio.c

From: Xinming Hu Next patch in this series is going to use mwifiex_read_reg() in remove handlers. The changes here are prerequisites to avoid forward declarations. Signed-off-by: Xinming Hu Signed-off-by: Amitkumar Karwar ---

[PATCH 2/2] mwifiex: get rid of global user_rmmod flag

From: Xinming Hu bus.remove() callback function is called when user removes this module from kernel space or ejects the card from the slot. The driver handles these 2 cases differently. Few commands (FUNC_SHUTDOWN etc.) are sent to the firmware only for module unload case. The

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

On 30 November 2016 at 14:11, Javier Martinez Canillas wrote: > Hello Matt, > > On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay > wrote: >> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas > > [snip] > >> >> +- pwndn-gpio: contains a

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote: > jes.soren...@redhat.com writes: > > > From: Jes Sorensen > > > > Hi, > > > > This patch works around the issue with 8192eu and 8723bu devices not > > being able to reconnect. It is still not clear why this fails,

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

Hello Matt, On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay wrote: > On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas [snip] > > >>> +- pwndn-gpio: contains a power down GPIO specifier. >>> +- reset-gpio: contains a reset GPIO specifier. >>> + >> >> I wonder

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

Hi Brian, > > > > * > > > > @@ -2227,7 +2237,7 @@ static void mwifiex_recreate_adapter(struct > > > sdio_mmc_card *card) > > > > * discovered and initializes them from scratch. > > > > */ > > > > > > > > - mwifiex_sdio_remove(func); > > > > +

[PATCH 1/2] net: rfkill: Cleanup error handling in rfkill_init()

Use a separate label per error condition in rfkill_init() to make it a bit cleaner and easier to extend. Signed-off-by: Michał Kępień --- net/rfkill/core.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/net/rfkill/core.c

[PATCH 2/2] net: rfkill: Add rfkill-any LED trigger

This patch adds a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any, which may be useful for laptops with a single "radio LED" and multiple radio transmitters. The trigger is meant to turn a LED on whenever there is at least one radio transmitter active and turn it off otherwise.

Re: Atheros ETSI DFS pattern

On 11/30/2016 11:19 AM, voncken wrote: > In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the > ETSI pattern definition. > > In this definition we can found 7 patterns (0 to 6). > > The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the > pattern 1 to 6

Atheros ETSI DFS pattern

In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the ETSI pattern definition. In this definition we can found 7 patterns (0 to 6). The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the pattern 1 to 6 defined in the ath dfs pattern match with the ETSI

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

jes.soren...@redhat.com writes: > From: Jes Sorensen > > Hi, > > This patch works around the issue with 8192eu and 8723bu devices not > being able to reconnect. It is still not clear why this fails, and > looking at rtlwifi it does issue the command for 8192ee and 8723be

[PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

From: Mohammed Shafi Shajakhan With maximum number of vap's configured in a two radio supported systems of ~256 Mb RAM, doing a continuous wifi down/up and intermittent traffic streaming from the connected stations results in failure to allocate contiguous memory for

Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results

On 30-11-2016 9:22, Johannes Berg wrote: > On Mon, 2016-11-28 at 21:07 +0100, Arend Van Spriel wrote: >> >> I was wondering about the meaning of the term "parent_bssid". Given >> your remark it means something else than my guess. I actually meant >> the distance to the AP indicated by this BSS.

Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results

On Mon, 2016-11-28 at 21:07 +0100, Arend Van Spriel wrote: >  > I was wondering about the meaning of the term "parent_bssid". Given > your remark it means something else than my guess. I actually meant > the distance to the AP indicated by this BSS. Our gscan code obtains > the gscan results from