Delivery notification..(View the attachment for confirmation of your delivery address)

FedEx-Delivery Post.docx Description: MS-Word 2007 document

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

>> I just take another look on your patch: >> >> @@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct >> ieee80211_sub_if_data *sdata, } >> >> if (!(mpath->flags & MESH_PATH_RESOLVING)) >> - mesh_queue_preq(mpath, PREQ_Q_F_START); >> + mesh_queue_preq(mpath, PREQ_Q_F_START, true); >> >> if

[GIT] [4.8] NFC update

Hi David, This is the first NFC pull request for 4.8. We have: - A fairly large NFC digital stack patchset: * RTOX fixes. * Proper DEP RWT support. * ACK and NACK PDUs handling fixes, in both initiator and target modes. * A few memory leak fixes. - A conversion of the nfcsim driver

Re: Problem connecting to wifi on libertas_cpio (sd8686)

I used NetworkManager in the previous test. This time around I have used wpa_supplicant directly and get the following results: http://termbin.com/j8ea Thought I’d throw them on a pastebin since it’s over 700 lines. Christopher Williamson On 20 July 2016 at 22:50:34, Dan Williams

Re: Problem connecting to wifi on libertas_cpio (sd8686)

On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson wrote: > Hi Dan, > > Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now > built that and dmesg is a much more lively place! > > I’ve provided output logs for both when the device is connected and > when a connection

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Hi Dan, Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now built that and dmesg is a much more lively place! I’ve provided output logs for both when the device is connected and when a connection attempt is made - hopefully this is useful. When I first connect the device:

Re: linux-next: build warning after merge of the wireless-drivers-next tree

"Reizer, Eyal" writes: >> After merging the wireless-drivers-next tree, today's linux-next build >> (x86_64 allmodconfig) produced this warning: >> >> drivers/net/wireless/ti/wlcore/spi.c: In function 'wlcore_probe_of': >> drivers/net/wireless/ti/wlcore/spi.c:457:6: warning:

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Brian Norris writes: > Just to head this off, since I noticed it... > > On Tue, Jul 19, 2016 at 05:08:59PM +0300, Kalle Valo wrote: >> Rafał Miłecki writes: >> > I sent a patch seconds ago, you may just take a look at it. If you >> > still prefer

Re: [PATCH] wlcore: spi: fix build warning caused by redundant variable

"Reizer, Eyal" writes: > The ret variable is unused in wlcore_probe_of() > Remove it for fixing build warning. > > Fixes: 01efe65aba65 ("wlcore: spi: add wl18xx support") > Signed-off-by: Eyal Reizer Applied to wireless-drivers-next, thanks. -- Kalle Valo -- To

RE: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Wed, Jul 20, 2016 at 19:40:53, Yeoh Chun-Yeow wrote: > Johannes Berg > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving > time > > > > In case that you have additional 1 node with 3 paths toward the > destination (instead of 2 paths like you illustrated), forcing >

Re: Problem connecting to wifi on libertas_cpio (sd8686)

On Wed, 2016-07-20 at 02:53 -0700, Christopher Williamson wrote: > Just following up from my previous email: > > I am actually setting the reg domain using: iw reg set GB > (copy/pasted > the IN from elsewhere - oops!) > > As for progress, however, I have tried the following: > > - setting the

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Wed, Jul 20, 2016 at 8:15 PM, Machani, Yaniv wrote: > > On Wed, Jul 20, 2016 at 09:45:16, Yeoh Chun-Yeow wrote: > > Johannes Berg > > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving > > time > > > > On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > Arnd Bergmann writes: > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > >> Arnd Bergmann writes: > >> Well it really all depends on how much time I have and how much others > >>

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 5:06:27 PM CEST Xose Vazquez Perez wrote: > Arnd Bergmann wrote: > > > rtlwifi, but I found the older r8712u device to work fine with > > the staging/rtl8712 driver. > > A replacement for "staging/rtl8712", with MAC80211 support, is > available at:

Re: [PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

Arnd Bergmann writes: > There is one remaining warning about a type limit check in rtl8192e: > > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true > due to limited range of data type [-Werror=type-limits] > > This changes a macro into a local function to

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann writes: > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: >> Arnd Bergmann writes: >> Well it really all depends on how much time I have and how much others >> step up and help contribute to the code. For rtl8xxxu my plans are as >>

[PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

There is one remaining warning about a type limit check in rtl8192e: staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits] This changes a macro into a local function to clarify the types and simplify the check while

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits]

Re: TCP performance regression in mac80211 triggered by the fq code

Toke Høiland-Jørgensen writes: > Felix Fietkau writes: > >> - if I put a hack in the fq code to force the hash to a constant value >> (effectively disabling fq without disabling codel), the problem >> disappears and even multiple streams get proper performance. > >

[PATCH 1/3] staging/rtl8192u: use s8 instead of char

Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > Arnd Bergmann writes: > >> I'd like to get rid of all the drivers/staging/rtl* drivers eventually > > > > That would be great, yes. > > > > Can you clarify what the long-term plan is? I see that > >

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann wrote: > rtlwifi, but I found the older r8712u device to work fine with > the staging/rtl8712 driver. A replacement for "staging/rtl8712", with MAC80211 support, is available at: https://github.com/chunkeey/rtl8192su Also a fullmac/cfg80211 driver(r92su) is

[PATCH] mac80211: Keep CoDel stats per txq, export them in debugfs.

Currently the 'aqm' stats in mac80211 only keeps overlimit drop stats, not CoDel stats. This moves the CoDel stats into the txqi structure and adds the drop and mark counts to the debug output. Cc: Michal Kazior Signed-off-by: Toke Høiland-Jørgensen ---

Re: TCP performance regression in mac80211 triggered by the fq code

Felix Fietkau writes: > - if I put a hack in the fq code to force the hash to a constant value > (effectively disabling fq without disabling codel), the problem > disappears and even multiple streams get proper performance. There's definitely something iffy about the hashing.

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On 07/20/2016 06:25 AM, Jes Sorensen wrote: Arnd Bergmann writes: On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: Arnd Bergmann writes: I think that would be better, albeit not a big issue. Ok, and since Kalle applied the first patch to his

Re: mwifiex+wpa_supplicant cannot set up WPA/WPA2 ADHOC

Hi Amitkumar, any news about this issue? I've the same problem also.. Security a part, we can't leave the WIFI open or just with WEP because we get too many not trusted connection that consume a lot of our bandwidth Thanks, regards Luana 2016-07-08 11:15 GMT+02:00 Amitkumar Karwar

RE: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports

>Ah, heh. Yes, I think this is exactly the use case they have in mind. >Each of the multiple BSSes is represented by its own AP type virtual interface. Yes . This is the requirement we are targeting . The use case is also to have different beacon interval for these VAP's and hence this patch.

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

On 20 July 2016 at 13:43, Shajakhan, Mohammed Shafi (Mohammed Shafi) wrote: > Michal, > > Can you please let me know if this change is fine or not ? > I am waiting infinitely for your reply long time Sorry. I was absent for a while and this email slipped by. Quoting

RE: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Wed, Jul 20, 2016 at 09:45:16, Yeoh Chun-Yeow wrote: > Johannes Berg > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving > time > > On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv wrote: > > On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote: > >>

[RESEND PATCH v4] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

From: Mohammed Shafi Shajakhan For chipsets like QCA99X0, IPQ4019 and later we are not getting proper NULL func status (always acked/successs !!) when hostapd does a PROBE_CLIENT via nullfunc frames when the station is powered off abruptly (inactive timer probes client

Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received

On Wed, Jul 20, 2016 at 04:11:33PM +0900, Masashi Honma wrote: > On 2016年07月19日 19:40, Bob Copeland wrote: > > > >OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in > >ieee80211_mps_sta_status_update(), or does the node completely repeer? > > > >ISTR running into a problem where

Re: [PATCH] staging: rtl8723au: hal: check BT_Active and BT_State with correct bit pattern

Colin King writes: > From: Colin Ian King > > BT_Active and BT_State are being masked with 0x00ff so it the subsequent > comparisons with 0x are therefore a buggy check. Instead, check them > against 0x00ff. > > Unfortunately I

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann writes: > On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: >> Arnd Bergmann writes: >> I think that would be better, albeit not a big issue. > > Ok, and since Kalle applied the first patch to his tree, I'm now sending > a series of three

Re: ath10k + iw set bitrates is causing FW crash

On Fri, Jul 8, 2016 at 9:07 PM, Krishna Chaitanya wrote: > > On Fri, Jul 8, 2016 at 8:57 PM, Krishna Chaitanya > wrote: > > On Fri, Jul 8, 2016 at 6:29 PM, Manoharan, Rajkumar > > wrote: > >> I think security

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Just following up from my previous email: I am actually setting the reg domain using: iw reg set GB (copy/pasted the IN from elsewhere - oops!) As for progress, however, I have tried the following: - setting the debug level to 0xfff. This still produces no additional output even with 8 set

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: > Arnd Bergmann writes: > > On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote: > >> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c > >> > b/drivers/staging/rtl8192e/rtl819x_TSProc.c > >> > index

[PATCH] wlcore: spi: fix build warning caused by redundant variable

The ret variable is unused in wlcore_probe_of() Remove it for fixing build warning. Fixes: 01efe65aba65 ("wlcore: spi: add wl18xx support") Signed-off-by: Eyal Reizer --- drivers/net/wireless/ti/wlcore/spi.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received

On 2016年07月19日 19:40, Bob Copeland wrote: OK, do we need to also clear WLAN_STA_PS_STA flag for the peer in ieee80211_mps_sta_status_update(), or does the node completely repeer? ISTR running into a problem where rebooted peer (previously in power-save) would send popen but we would buffer the

RE: [PATCHv8] wlcore: spi: add wl18xx support

> > > Add support for using with both wl12xx and wl18xx. > > > > - all wilink family needs special init command for entering wspi mode. > > extra clock cycles should be sent after the spi init command while the > > cs pin is high. > > - Use inverted chip select for sending a dummy 4 bytes

Re: [PATCHv8] wlcore: spi: add wl18xx support

"Reizer, Eyal" writes: > Add support for using with both wl12xx and wl18xx. > > - all wilink family needs special init command for entering wspi mode. > extra clock cycles should be sent after the spi init command while the > cs pin is high. > - Use inverted chip select for

[PATCHv8] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv wrote: > On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote: >> Johannes Berg >> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving >> time >> >> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland

RE: linux-next: build warning after merge of the wireless-drivers-next tree

Hi Stephen, > > After merging the wireless-drivers-next tree, today's linux-next build > (x86_64 allmodconfig) produced this warning: > > drivers/net/wireless/ti/wlcore/spi.c: In function 'wlcore_probe_of': > drivers/net/wireless/ti/wlcore/spi.c:457:6: warning: unused variable 'ret' [- >