Re: Research + questions on brcmfmac and support for monitor mode

On 5/15/2018 2:29 PM, Rafał Miłecki wrote: I'm interested in adding support for monitor mode to the brcmfmac. I did some early research on firmware capabilities & behavior using various firmwares I could find for my devices: 43602a1, 4366b1, 4366c0 (BCM4366 and BCM4366E). I am interested too

Re: [PATCH 4/8] mwifiex: support sysfs initiated device coredump

On 5/15/2018 10:22 PM, kbuild test robot wrote: Hi Arend, I love your patch! Yet something to improve: [auto build test ERROR on next-20180515] [cannot apply to wireless-drivers-next/master wireless-drivers/master bluetooth-next/master v4.17-rc5 v4.17-rc4 v4.17-rc3 v4.17-rc5] [if your patch

Re: [PATCH] cfg80211: Use correct GFP_ mask in cfg80211_del_sta_sinfo()

Dan Carpenter writes: > Smatch complains that we should use the passed in "gfp" instead of hard > coding GFP_KERNEL. I looked at some of the callers and this would > probably be a bug for rtw_cfg80211_indicate_sta_disassoc() which uses > GFP_ATOMIC and a NULL "sinfo".

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

Peter Oh writes: >> Sure, every software change can cause regressions. But the thing is that >> this isn't an optional, ath10k has to have this to be able to continue >> using DFS channels. > > Kalle, you said you don't know which exact FCC requirement this is for >

Re: [PATCH v2] mac80211: Fix wlan freezes under load at rekey

On Wed, 2018-05-16 at 00:41 +0200, Alexander Wetzel wrote: > > I'm on very thin ice here, I think we all are, since we're talking about interoperability :-) > but my impression was that this should work > without too many problems for all (most?) systems: > - An aggregation session is only

Re: [PATCH 2/2] wlcore: Add support runtime PM

Michael Nazzareno Trimarchi writes: >> @@ -315,15 +319,17 @@ static ssize_t dynamic_fw_traces_write(struct file >> *file, >> if (unlikely(wl->state != WLCORE_STATE_ON)) >> goto out; >> >> - ret = wl1271_ps_elp_wakeup(wl); >> - if

Re: ath10k wake_tx_queue issues

Hello, This sounds exactly like the issue I just submitted a patch for. Can you test https://patchwork.kernel.org/patch/10399613/ if that solves the issue? Am 15.05.2018 um 22:31 schrieb Niklas Cassel: > On Tue, May 15, 2018 at 04:13:48PM +0200, Toke Høiland-Jørgensen wrote: >> [ Adding Felix

Re: [PATCH 4/8] mwifiex: support sysfs initiated device coredump

Arend van Spriel writes: > On 5/15/2018 10:22 PM, kbuild test robot wrote: >> Hi Arend, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on next-20180515] >> [cannot apply to wireless-drivers-next/master wireless-drivers/master >>

[PATCH] cfg80211: Use correct GFP_ mask in cfg80211_del_sta_sinfo()

Smatch complains that we should use the passed in "gfp" instead of hard coding GFP_KERNEL. I looked at some of the callers and this would probably be a bug for rtw_cfg80211_indicate_sta_disassoc() which uses GFP_ATOMIC and a NULL "sinfo". Fixes: 52539ca89f36 ("cfg80211: Expose TXQ stats and

Re: ath10k wake_tx_queue issues

Niklas Cassel writes: > [ .. snip .. ] >> > Sure, the regular way ath10k_mac_op_wake_tx_queue is called is via >> > ieee80211_subif_start_xmit => __ieee80211_subif_start_xmit => >> > ieee80211_xmit_fast >> > => ieee80211_queue_skb => drv_wake_tx_queue. >> > >> > But I

Re: [PATCH 1/2] wlcore: Make sure PM calls are paired

* Tony Lindgren [180515 16:15]: > The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is > unpaired. Let's remove it and add paired calls to wl1271_recovery_work() > instead in preparation for changing things to use runtime PM. > > Signed-off-by: Tony Lindgren

Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

Arend van Spriel writes: > Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") > it is possible to initiate a device coredump from user-space. This > patch adds support for it adding the .coredump() driver callback. > As there is no longer a need to

Re: [PATCH 1/2] wlcore: Make sure PM calls are paired

* Tony Lindgren [180515 16:15]: > The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is > unpaired. Let's remove it and add paired calls to wl1271_recovery_work() > instead in preparation for changing things to use runtime PM. Looks like this causes at least a

[PATCH 03/10] wcn36xx: don't disable RX IRQ from handler

There's no need to disable the IRQ from inside its handler. Instead just grab the spinlock of the channel that is being processed. Signed-off-by: Daniel Mack --- drivers/net/wireless/ath/wcn36xx/dxe.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-)

[PATCH 00/10] Some more patches for wcn36xx

Here are some more patches for the wcn36xx driver that emerged from reviews and my attempts to fix the connection timeout issues. Some of them merely bring the driver in sync with what the "prima" downstream driver is doing, and they seemingly make the driver more stable. Others just apply some

[PATCH 04/10] wcn36xx: clear all masks in RX interrupt

Like on the TX side, check for the interrupt reason when the RX interrupt is latched and clear the ERR, DONE and ED masks. This seems to help with connection timeouts and network stream starvatations. And FWIW, the downstream driver does the same thing. Note that in analogy to the TX side,

[PATCH 07/10] wcn36xx: set PREASSOC and IDLE stated when BSS info changes

When a BSSID is joined, set the link status to 'preassoc', and set it to 'idle' when the BSS is deleted. This is what the downstream driver is doing, and it seems to improve the reliability during connect/disconnect stress tests. Signed-off-by: Daniel Mack ---

[PATCH 05/10] wcn36xx: only handle packets when ED or DONE bit is set

On RX and TX interrupts, check for the WCN36XX_CH_STAT_INT_ED_MASK or WCN36XX_CH_STAT_INT_DONE_MASK in the interrupt reason register, and only handle packets when it is set. This way, reap_tx_dxes() is only invoked when needed. This brings the dequeing logic in line with what the prima downstream

[PATCH 06/10] wcn36xx: consider CTRL_EOP bit when looking for valid descriptors

In reap_tx_dxes(), when we iterate over the linked descriptors, only consider such valid that have WCN36xx_DXE_CTRL_EOP set. This is what the prima downstream driver is doing as well. Signed-off-by: Daniel Mack --- drivers/net/wireless/ath/wcn36xx/dxe.c | 4 +++- 1 file

[PATCH 09/10] wcn36xx: simplify wcn36xx_smd_open()

Drop the extra warning about failed allocations, both the core and the only caller of this function will warn loud enough in such cases. Signed-off-by: Daniel Mack --- drivers/net/wireless/ath/wcn36xx/smd.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-)

[PATCH 10/10] wcn36xx: improve debug and error messages for SMD

Add a missing newline in wcn36xx_smd_send_and_wait() and also log the command request and response type that was processed. Signed-off-by: Daniel Mack --- drivers/net/wireless/ath/wcn36xx/smd.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git

[PATCH 08/10] wcn36xx: drain pending indicator messages on shutdown

When the interface is shut down, wcn36xx_smd_close() potentially races against the queue worker. Make sure to cancel the work, and then free all the remnants in hal_ind_queue manually. This is again just a theoretical issue, not something that was triggered in the wild. Signed-off-by: Daniel

[PATCH 02/10] wcn36xx: set DMA mask explicitly

The device takes 32-bit addresses only, so inform the DMA API about it. This is the default on msm8016, so that doesn't change anything, but it's best practice to be explicit. Signed-off-by: Daniel Mack --- drivers/net/wireless/ath/wcn36xx/main.c | 6 ++ 1 file changed, 6

[PATCH 01/10] wcn36xx: fix buffer commit logic on TX path

When wcn36xx_dxe_tx_frame() is entered while the device is still processing the queue asyncronously, we are racing against the firmware code with updates to the buffer descriptors. Presumably, the firmware scans the ring buffer that holds the descriptors and scans for a valid control descriptor,

Re: [PATCH] mac80211: invoke software scan when hardware scan returns EPERM

Sushant Kumar Mishra writes: > From: Sanjay Kumar Konduri > > Currently, software scan in mac80211 is used by drivers, which don't > implement hardware scan. However some drivers which have implemented > hardware scan may also

Re: [v2] rsi: add support for hardware scan offload

Sushant Kumar Mishra writes: > From: Prameela Rani Garnepudi > > With the current approach of scanning, roaming delays are observed. > Firmware has support for back ground scanning. To get this advantage, > mac80211 hardware scan is

[PATCH V2 5/6] brcmfmac: trigger memory dump upon firmware halt signal

From: Franky Lin PCIe dongle firmware signals a halt/trap through mailbox interrupt. Trigger a memory dump upon receiving such signal could help to provide useful information for issue debug. Reviewed-by: Arend van Spriel Signed-off-by:

[PATCH V2 1/6] brcmfmac: move ALLFFMAC variable in flowring module

The only user of ALLFFMAC is the flowring module so no need to expose it in a header file. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van

[PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") it is possible to initiate a device coredump from user-space. This patch adds support for it adding the .coredump() driver callback. As there is no longer a need to initiate it through debugfs remove that code. Signed-off-by:

[PATCH V2 2/6] brcmfmac: add support for sysfs initiated coredump

The driver already supports device coredump initiated by firmware event. Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") it is also possible to initiate it from user-space through sysfs. This patch adds support for SDIO and PCIe devices. Reviewed-by: Hante Meuleman

[PATCH V2 6/6] brcmfmac: trigger memory dump on SDIO firmware halt message

From: Franky Lin Attempt to dump dongle memory for debug upon receiving firmware halt message through dongle to host mail box interrupt. Reviewed-by: Arend van Spriel Signed-off-by: Franky Lin Signed-off-by: Arend

[PATCH V2 0/6] brcmfmac: coredump functionality and fixes

This series is intended for 4.18: * make ALLFFMAC variable static. * support user-space initiated coredump. The first patch in this series applies to the master branch of the wireless-drivers-next repository. The remaining patches related to coredump functionality are dependent upon a commit

[PATCH V2 4/6] brcmfmac: validate user provided data for memdump before copying

From: Franky Lin In patch "brcmfmac: add support for sysfs initiated coredump", a new scenario of brcmf_debug_create_memdump was added in which the user of the function might not necessarily provide prefix data. Hence the function should not assume the data is always

Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac

Pkshih writes: >> And I even read all 19 commit logs and there was no mention of why this >> is needed either. I cannot just blindly apply patches without knowing >> what they do. >> > > This new module halmac is an abstract layer for Realtek WiFi MAC to provide > common

Re: Research + questions on brcmfmac and support for monitor mode

On 16 May 2018 at 10:37, Arend van Spriel wrote: > On 5/15/2018 2:29 PM, Rafał Miłecki wrote: >> >> I'm interested in adding support for monitor mode to the brcmfmac. I did >> some early research on firmware capabilities & behavior using various >> firmwares I could

Re: [PATCH net-next] ath10k: Remove useless test before clk_disable_unprepare

YueHaibing writes: > clk_disable_unprepare() already checks that the clock pointer is valid. > No need to test it before calling it. > > Signed-off-by: YueHaibing Just a note that ath10k patches are applied to my ath.git tree, not to net-next. So

Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac

Krishna Chaitanya writes: > On Mon, Apr 30, 2018 at 8:10 AM, Pkshih wrote: >> >> >> > -Original Message- >> > From: Barry Day [mailto:brise...@gmail.com] >> > Sent: Saturday, April 28, 2018 6:42 AM >> > To: Pkshih >> > Cc: Kalle Valo;

Re: [v2] rsi: add support for hardware scan offload

On Wed, May 16, 2018 at 5:03 PM, Kalle Valo wrote: > Sushant Kumar Mishra writes: > >> From: Prameela Rani Garnepudi >> >> With the current approach of scanning, roaming delays are observed. >> Firmware has support for

[PATCH net-next] ath10k: Remove useless test before clk_disable_unprepare

clk_disable_unprepare() already checks that the clock pointer is valid. No need to test it before calling it. Signed-off-by: YueHaibing --- drivers/net/wireless/ath/ath10k/ahb.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git

[PATCH 1/2] NFC: st95hf: initialize semaphore and mutex earlier

'rm_lock' and 'exchange_lock' need to be ready before the IRQ handler has a chance to fire. This fixes the oops below. [1.040255] Internal error: Oops: 9604 [#1] PREEMPT SMP [...] [1.181564] Call trace: [1.188591] Exception stack(0x0a473c40 to 0x0a473d80) [

Re: [PATCH net-next] ath10k: Remove useless test before clk_disable_unprepare

On 2018/5/16 19:42, Kalle Valo wrote: > YueHaibing writes: > >> clk_disable_unprepare() already checks that the clock pointer is valid. >> No need to test it before calling it. >> >> Signed-off-by: YueHaibing > > Just a note that ath10k patches are

Re: [PATCH V2 1/6] brcmfmac: move ALLFFMAC variable in flowring module

Arend van Spriel writes: > The only user of ALLFFMAC is the flowring module so no need to > expose it in a header file. > > Reviewed-by: Hante Meuleman > Reviewed-by: Pieter-Paul Giesberts >

Re: [PATCH V2 3/6] mwifiex: support sysfs initiated device coredump

On 5/16/2018 3:50 PM, Kalle Valo wrote: Arend van Spriel writes: Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") it is possible to initiate a device coredump from user-space. This patch adds support for it adding the .coredump() driver

Re: ath10k wake_tx_queue issues

Hello Niklas Quick question: Are you using my patch: "ath10k: add htt_tx num_pending window"? I assume (from your logs below) that you are not... See more comments below. I guess the best way to describe this is to show my ftrace buffer: ksoftirqd/2-21[002] .ns474.711744:

Re: ath10k wake_tx_queue issues

On Wed, May 16, 2018 at 07:54:54AM +0200, Alexander Wetzel wrote: > Hello, > > This sounds exactly like the issue I just submitted a patch for. > Can you test https://patchwork.kernel.org/patch/10399613/ if that solves > the issue? Hello Alexander, I just tried you fix, and unfortunately it

rtl8812au with hostapd uses only one antenna of Netis WF2190 AC1200 (2x2)

I am using the Netis WF2190 AC1200 USB WiFi adapter with driver rtl8812au-master in conjunction with the patch hostapd-rtl871xdrv-master. https://wikidevi.com/wiki/Netis_WF2190 When the Netis is configured as a client, both antennas have transmit power about +13dBm. When the Netis is

Re: [linux-firmware] Version in WHENCE file

On Mon, 2018-05-07 at 09:47 +0200, Sedat Dilek wrote: > On Sun, May 6, 2018 at 3:07 PM, Luciano Coelho com> wrote: > > On Sun, 2018-05-06 at 14:46 +0200, Sedat Dilek wrote: > > > Hi Luca, > > > > > > I hope I catched the correct MLs (not sure if linux-firmware has > > > a