Re: Monitor interface TX performance boost

On Sun, Feb 7, 2016 at 9:09 AM, Kalle Valo wrote: > Nikolay Martynov writes: > >> I'm seeing strange behavior on my intel 6300 card. >> >> If I measure TX performance just after boot (iperf in tcp mode), I get >> this: >> >> [ 3] 0.0-10.1 sec 11.2 MBytes 9.32 Mbits/sec >> >> But if cre

Re: [RFC v2] mac80211: add A-MSDU tx support

On Fri, Feb 5, 2016 at 12:41 PM, Felix Fietkau wrote: > Requires software tx queueing support. frag_list support (for zero-copy) > is optional. > > Signed-off-by: Felix Fietkau Looks nice! This would allow us to create aggregates of TCP Acks, the problem is that when you are mostly receiving dat

Re: [1/8] mwifiex: display right transmit packet delay

> From: Xinming Hu > > drv_pkt_delay_max should be assigned non-zero value, so that > packet delay can be accumulate in the right way. > > Signed-off-by: Xinming Hu > Signed-off-by: Amitkumar Karwar Thanks, 8 patches applied to wireless-drivers-next.git: 6970cd446c25 mwifiex: display right

Re: [2/3] net: wireless: rt2x00: Pointer issue

> Code Style: pointer is declared wrong > > Signed-off-by: Paul McQuade > Acked-by: Helmut Schaa This patch didn't apply, so please resend. Kalle -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [1/3] net: wireless: rt2x00: Space issue

> Removed empty spaces before/after parenthesis > > Signed-off-by: Paul McQuade > Acked-by: Helmut Schaa Thanks, 2 patches applied to wireless-drivers-next.git: b2cc2dd8ebb8 net: wireless: rt2x00: Space issue 5b451715e94d net: wireless: rt2x00: Space Required 1 patches skipped: [2/3] net: w

Re: net: wireless: rt2x00: Fixed Spacing issues

> Removed empty spaces before/after parenthesis > > Signed-off-by: Paul McQuade > Acked-by: Helmut Schaa Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org

Re: Monitor interface TX performance boost

Nikolay Martynov writes: > I'm seeing strange behavior on my intel 6300 card. > > If I measure TX performance just after boot (iperf in tcp mode), I get this: > > [ 3] 0.0-10.1 sec 11.2 MBytes 9.32 Mbits/sec > > But if create and enable monitor interface (with command like 'sudo > iw ph

Re: [PATCH] staging: wilc1000: fix compilation without CONFIG_PM

On Fri, Feb 05, 2016 at 04:21:50PM +0100, Arnd Bergmann wrote: > After the addition of the wakeup code in wilc1000, it no longer > builds when CONFIG_PM is disabled: > > drivers/staging/wilc1000/wilc_wfi_cfgoperations.c: In function > 'wilc_create_wiphy': > drivers/staging/wilc1000/wilc_wfi_cfgop

Re: [PATCH] staging: wilc1000: Fix compilation error when CONFIG_PM disabled

On Fri, Feb 05, 2016 at 02:40:27PM +0900, Glen Lee wrote: > Commit 73584a40d748 ("staging: wilc1000: add ops resuem/suspend/wakeup in > cfg80211") causes following compilation error. This patch fixes this by > using suspend/resume under CONFIG_PM. > > drivers/staging/wilc1000/wilc_wfi_cfgoperation

Monitor interface TX performance boost

Hi. I'm seeing strange behavior on my intel 6300 card. If I measure TX performance just after boot (iperf in tcp mode), I get this: [ 3] 0.0-10.1 sec 11.2 MBytes 9.32 Mbits/sec But if create and enable monitor interface (with command like 'sudo iw phy phy0 interface add moni0 type mon

[PATCH v3 1/3] staging: rtl8723au: use list_for_each_entry*()

Use list_for_each_entry*() instead of list_for_each*() to simplify the code. Signed-off-by: Geliang Tang --- Changes in v3: - split it into three patches. Changes in v2: - drop the coding style fixing in v1. --- drivers/staging/rtl8723au/core/rtw_ap.c | 55 --- driver

[PATCH v3 2/3] staging: rtl8723au: core: rtw_recv: remove useless codes

There are some useless codes in rtw_free_recvframe23a_queue() and recvframe_defrag(), so remove them. Signed-off-by: Geliang Tang --- Changes in v3: - split it into three patches. Changes in v2: - drop the coding style fixing in v1. --- drivers/staging/rtl8723au/core/rtw_recv.c | 7 +-- 1

[PATCH v3 3/3] staging: rtl8723au: whitespace and blank line cleaning

This patch cleans whitespaces and blank lines surrounding list_for_each_entry*(). Signed-off-by: Geliang Tang --- Changes in v3: - split it into three patches. Changes in v2: - drop the coding style fixing in v1. --- drivers/staging/rtl8723au/core/rtw_ap.c | 41 ++

Re: [v3,1/6] libertas: fix pointer bugs for PS_MODE commands

> struct cmd_ds_802_11_ps_mode > contains the command header and a pointer to it was > initialized with data points to the body which leads to > mis-interpretation of the cmd_ds_802_11_ps_mode.action member. > cmd[0] contains the header, &cmd[1] points beyond that. > cmdnode->cmdbuf is a pointer t

Re: mwifiex: fix a reversed condition

> The NULL test here is reversed. > > Fixes: 7d7f07d8c5d3 ('mwifiex: add wowlan net-detect support') > Signed-off-by: Dan Carpenter Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to

Re: mwifiex: fix bandwidth display problem

> From: Nachiket Kukade > > Instead of using HT info from beacon IEs, use HT info from > association response frame to update bandwidth in > cfg80211_get_channel handler. > > Signed-off-by: Nachiket Kukade > Signed-off-by: Amitkumar Karwar Thanks, applied to wireless-drivers-next.git. Kalle

Re: [v2] hostap: avoid uninitialized variable use in hfa384x_get_rid

> The driver reads a value from hfa384x_from_bap(), which may fail, > and then assigns the value to a local variable. gcc detects that > in in the failure case, the 'rlen' variable now contains > uninitialized data: > > In file included from > ../drivers/net/wireless/intersil/hostap/hostap_pci.c

Re: brcmfmac: sdio: Increase the default timeouts a bit

> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems > the card responds very quickly most of the time, unfortunately during > initialisation it sometimes seems to take just a bit over 2 seconds to > respond. > > This results intialization failing with message like: > brcm

Re: [PATCH] brcmfmac: treat NULL character in NVRAM as separator

Rafał Miłecki writes: > Platform NVRAM (stored on a flash partition) has entries separated by a > NULL (\0) char. Our parsing code switches from VALUE state to IDLE > whenever it meets a NULL (\0). When that happens our IDLE handler should > simply consume it and analyze whatever is placed ahead.

Re: [PATCH 0/5] brcmfmac: support for new 14e43:4365 card with BCM4366

Rafał Miłecki writes: > I got D-Link DIR-885L with two 14e4:4365 PCI cards both using BCM4366 chipset. > It seems to have newer ChipCommon and separated PMU core so I needed these > patches on top of recent Broadcom's work. > > Please note this patchset depends on: > [PATCH 2/2] bcma: support PMU

Re: [PATCH] bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142

Rafał Miłecki writes: > It seems 14e4:4365 pattern is too generic as there are two devices: > 1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset > 2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset > The later one was found in D-Link DIR-885L router and we want to let > brcmfmac handle it. > >

Re: [PATCH] bcma: add support for BCM47094

Rafał Miłecki writes: > It's another SoC with 32 GPIOs and simplified watchdog handling. It was > tested on D-Link DIR-885L. > > Signed-off-by: Rafał Miłecki Manually applied to wireless-drivers-next.git, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux

Re: [PATCH] bcma: init serial console directly from ChipCommon code

Rafał Miłecki writes: > UART is connected to and controlled over ChipCommon core. It doesn't > have much to do with MIPS core (where we initialize it currently) > except just existing on embedded systemms. There isn't point of such > cross-core initialization (and we needed #ifdef anyway) so just

Re: [PATCH] brcmfmac: fix setting primary channel for 80 MHz width

Rafał Miłecki writes: > First of all it changes the way we calculate primary channel offset. If > we use e.g. 80 MHz channel with primary frequency 5180 MHz (which means > center frequency is 5210 MHz) it makes sense to calculate primary offset > as -30 MHz. > Then it fixes values we compare prim

Re: [PATCH 1/2] bcma: use _PMU_ in all names of PMU registers

Rafał Miłecki writes: > PMU (Power Management Unit) seems to be a separated piece of hardware, > just accessed using ChipCommon core registers. In recent Broadcom > chipsets PMU is not bounded to CC but available as separated core. > > To make code cleaner & easier to review (for a correct R/W ac

Re: [PATCH 1/2] bcma: identify bus cores (devices) found on BCM47189

Rafał Miłecki writes: > Add missing defines and print proper names. > > Signed-off-by: Rafał Miłecki Manually applied both patches to wireless-drivers-next.git, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to major

Re: [PATCH] bcma: support identifying MX25L25635F serial flash

Rafał Miłecki writes: > It's a Macronix 32 MiB flash found on board with BCM47189 SoC. > > Signed-off-by: Rafał Miłecki Manually applied to wireless-drivers-next.git, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to

Re: pull request: iwlwifi-next 2016-01-31

"Grumbach, Emmanuel" writes: > Hi Kalle, > > This is a pull request for 4.6. Please pull. Thanks! > > The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > (2016-01-12 18:57:02 -0800) > > are availa

Re: rtlwifi: fix broken VHT support

> When using a 5G-capable device with VHT (802.11ac) rates enabled was not > working (packets were not delivered) and the following mac80211 warning > was printed: > > WARNING: CPU: 3 PID: 2253 at net/mac80211/rate.c:625 > ieee80211_get_tx_rates+0x22e/0x620 [mac80211]() > Modules linked in: rtl8