Re: [PATCH] linux-firmware: add wil6210 firmware 4.1.0.55

Kyle McMartin writes: > On Sun, May 21, 2017 at 03:48:57PM +0300, Maya Erez wrote: >> This is the latest firmware from wil6210 4.1 firmware branch. >> >> Signed-off-by: Maya Erez >> --- >> WHENCE | 10 ++ >> wil6210.brd | Bin 0 ->

Re: [PATCH] linux-firmware: add wil6210 firmware 4.1.0.55

On Sun, May 21, 2017 at 03:48:57PM +0300, Maya Erez wrote: > This is the latest firmware from wil6210 4.1 firmware branch. > > Signed-off-by: Maya Erez > --- > WHENCE | 10 ++ > wil6210.brd | Bin 0 -> 3588 bytes > wil6210.fw | Bin 0 -> 350748 bytes >

Re: [PATCH] brcmfmac: Fix kernel oops on resume when request firmware fails.

Hi Enric, On Tue, May 23, 2017 at 11:07 AM, Enric Balletbo i Serra wrote: > When request firmware fails, brcmf_ops_sdio_remove is being called and > brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle > the kernel hangs on resume due a NULL

Re: [PATCHv4] wlcore: add wl1285 compatible

Hi, On Mon, May 22, 2017 at 11:50:04AM -0500, Rob Herring wrote: > [...] > >> >> Thanks, I'll take it then. Not sure why Sebastian was suggested to > >> >> submit this patch via your tree in the first place. > >> >> > >> >> https://patchwork.kernel.org/patch/9713645/ > >> > > >> > Thanks. The

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

On 22/05/17 23:02, Arend Van Spriel wrote: > > > On 22-5-2017 14:09, Arend van Spriel wrote: >> On 5/22/2017 12:57 PM, Johannes Berg wrote: >>> On Mon, 2017-05-22 at 12:36 +0200, Sander Eikelenboom wrote: Hi, I encountered this splat with 4.12-RC2. >>> >>> Ugh, yeah, I should've

[PATCH] brcmfmac: Fix kernel oops on resume when request firmware fails.

When request firmware fails, brcmf_ops_sdio_remove is being called and brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle the kernel hangs on resume due a NULL pointer dereference in resume function. Steps to reproduce the problem: - modprobe brcmfmac without the firmware

Re: git repo with Redpine changes

Hi Amit! On Tue, 2017-05-23 at 17:00 +0530, amit karwar wrote: > On Wed, May 17, 2017 at 1:41 PM, Alexey Brodkin > wrote: > > > > Hello Amitkumar, Prameela, > > > > I was lucky enough to get hold of RS9113 Evaluation Kit and now I'm trying > > to get it working

Re: [v2,1/5] wil6210: low level RF sector API

Maya Erez wrote: > From: Lior David > > Added vendor commands for low level control over > RF sectors. It allows user space a fine-grained control > over RF characteristics for TX and RX, such as direction > and gain of TX/RX. Main usages

Re: ath10k: Fix reported HT MCS rates with NSS > 1

Sven Eckelmann wrote: > The QCA4019 firmware 10.4-3.2.1-00050 reports only HT MCS rates between > 0-9. But 802.11n MCS rates can be larger than that. For example a 2x2 > device can send with up to MCS 15. > > The firmware encodes the higher MCS rates using the NSS

Re: [v2] ath10k: remove unnecessary code

"Gustavo A. R. Silva" wrote: > The array fields in struct wmi_start_scan_arg that are checked here are > fixed size arrays so they can never be NULL. > > Addresses-Coverity-ID: 1260031 > Cc: Arend Van Spriel > Cc: Kalle Valo

Re: wcn36xx: Close SMD channel on device removal

Bjorn Andersson wrote: > The SMD channel is not the primary WCNSS channel and must explicitly be > closed as the device is removed, or the channel will already by open on > a subsequent probe call in e.g. the case of reloading the kernel module. > > This issue was

[PATCH v2 2/2] mac80211: enable VHT for mesh channel processing

Signed-off-by: Simon Wunderlich --- net/mac80211/mesh.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c index 872a05606f06..d526fbd81d10 100644 --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -989,12

[PATCH v2 0/2] extend mac80211 mesh DFS and CSA functionality

This patchset includes the remaining two patches for the CSA handling, with Johannes change suggestions integrated. Cheers, Simon Simon Wunderlich (2): mac80211: mesh: support sending wide bandwidth CSA mac80211: enable VHT for mesh channel processing net/mac80211/ieee80211_i.h | 2

[PATCH v2 1/2] mac80211: mesh: support sending wide bandwidth CSA

To support HT and VHT CSA, beacons and action frames must include the corresponding IEs. Signed-off-by: Simon Wunderlich --- Changes to PATCHv1 (Thanks Johannes) * change patch subject (originally: mac80211: add wide bandwidth channel switch announcement to CSA action

Re: [PATCH] cfg80211: make cfg80211_sched_scan_results() work from atomic context

On Tue, 2017-05-23 at 09:58 +0100, Arend van Spriel wrote: > Drivers should be able to call cfg80211_sched_scan_results() from > atomic > context. However, with the introduction of multiple scheduled scan > feature > this requirement was not taken into account resulting in regression > shown >

pull-request: mac80211 2017-05-23

Hi Dave, I have just two fixes here, one of the scheduled scan issue that Sander Eikelenboom found, and the other properly makes mesh more strictly check its extension headers. Please pull and let me know if there's any problem. Thanks, johannes The following changes since commit

[PATCH] cfg80211: make cfg80211_sched_scan_results() work from atomic context

Drivers should be able to call cfg80211_sched_scan_results() from atomic context. However, with the introduction of multiple scheduled scan feature this requirement was not taken into account resulting in regression shown below. [ 119.021594] BUG: scheduling while atomic:

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

On 23-5-2017 9:22, Johannes Berg wrote: > On Tue, 2017-05-23 at 09:19 +0200, Arend Van Spriel wrote: >> >>> WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held()); >> >> Thought about something like this after sending the email. So there >> are two call sites. One for scheduled scan

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

On Tue, 2017-05-23 at 09:19 +0200, Arend Van Spriel wrote: > > > WARN_ON_ONCE(!rcu_read_lock_held() && !lockdep_rtnl_is_held()); > > Thought about something like this after sending the email. So there > are two call sites. One for scheduled scan results notification and > one in scheduled

Re: 4.12-RC2 BUG: scheduling while atomic: irq/47-iwlwifi

On 22-5-2017 23:04, Johannes Berg wrote: > Hi Arend, > > Sorry, I forgot that the original message wasn't Cc'ed to the wireless > list, only netdev. That explains. Not subscribed to that. >> +++ b/net/wireless/scan.c >> @@ -322,9 +322,7 @@ static void cfg80211_del_sched_scan_req(struct >>

[PATCH v4 4/5] mwifiex: usb: add timer to flush aggregation packets

From: Xinming Hu Aggregation will wait for next packet until limit aggr size/number reach. Packet might be drop and also packet dequeue will be stop in some cases. This patch add timer to flush packets in aggregation list to avoid long time waiting. Signed-off-by: Xinming Hu

[PATCH v4 1/5] mwifiex: use variable interface header length

From: Xinming Hu Usb tx aggregation feature will utilize 4-bytes bus interface header, otherwise it will be set to zero in default case. Signed-off-by: Xinming Hu Signed-off-by: Cathy Luo Signed-off-by: Ganapathi Bhat

[PATCH v4 5/5] mwifiex: check next packet length for usb tx aggregation

From: Xinming Hu The next packet length will be used by interface driver, to check if the next packet still could be aggregated. Signed-off-by: Xinming Hu Signed-off-by: Cathy Luo Signed-off-by: Ganapathi Bhat --- v3:

[PATCH v4 2/5] mwifiex: usb: kill urb before free its memory

From: Xinming Hu we have observed host system hang when device firmware crash, stack trace show it was an use-after-free case: previous submitted urb will be holding in usbcore, and given back to device driver when device disconnected, while the urb have been freed in usb

[PATCH v4 3/5] mwifiex: usb: transmit aggregation packets

From: Xinming Hu Instead of using 4KB packet buffer for data transfer, new chipset have more device memory. This patch try to aggregation packets in an 16KB buffer. In this way, totally usb transaction cost will be reduced. Thoughput test on usb 2.0 show both TCP TX and UPD TX

Re: Re: [PATCH v3 5/6] mwifiex: do not aggregate tcp ack in usb tx aggregation queue

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年5月20日 0:43 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; Zhiyuan > Yang; Cathy Luo; Xinming Hu; Ganapathi Bhat > Subject: [EXT] Re: [PATCH v3 5/6]

RE: [EXT] Re: [PATCH v3 5/6] mwifiex: do not aggregate tcp ack in usb tx aggregation queue

Hi Brain, > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2017年5月20日 0:43 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; Zhiyuan > Yang; Cathy Luo; Xinming Hu; Ganapathi Bhat > Subject: [EXT] Re: [PATCH v3 5/6]