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 an
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 param
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 is
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 doe
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 was expecting the call to ie
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
>> bluetooth-next/master v4.17-rc5 v4
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".
>
> Fixes: 52539ca89f36 ("c
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 (ret < 0)
>> + ret = pm_
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
> in another email thread. Then
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 find for my devices: 43602a1, 4
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 a/drivers/net/wireless/ath/ath10k/ahb.c
b/
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 sometimes want to use software scan in mac80211.
> Such drivers can r
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 implemented, which decides type of scan to
> do based on connec
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 adding net-next to the subject is wrong, but no
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; larry.fin...@lwfinger.net; linux-wireless@vger.kernel
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 interfaces to access WiF
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 applied to my ath.git tree, not to
> net-next.
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: Are
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
Reviewed-b
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 van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++
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: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/
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 Spriel
---
Hi Kalle,
I recall Joe Perches posted patches dealing with broadcast address de
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 pr
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 valid and should perform a
ch
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 back ground scanning. To get this advantage,
>> mac80211 hardware scan is imp
Pkshih writes:
> On Mon, 2018-04-30 at 14:03 +0530, Krishna Chaitanya wrote:
>> 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:
'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)
[1.19
The skb that is passed in to ->in_send_cmd() is freed by the core when the
function returns. Calling kfree_skb() on it from the driver callback will
hence lead to a double-free.
Signed-off-by: Daniel Mack
---
drivers/nfc/st95hf/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/
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
> Reviewed-by: Franky Lin
> Signed-off-by: Arend van Spriel
> ---
> Hi Kalle,
>
> I recall Joe Perches p
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 initiate it through debugfs re
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,
an
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(-)
diff --git a/drivers/ne
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 bes
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, WCN36X
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
---
drivers/net/wireless/ath/wcn36xx/m
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
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 changed, 3 insertions(+)
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(-)
diff --git a/drivers/
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 a/drivers/net/wirele
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 Mack
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 insertions(+)
diff
* 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 warning at
drivers/n
* 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
> ---
> drivers/net
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: ath
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 callback.
As there is no longer a nee
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 config
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
> > > ML,
> > > I did no
47 matches
Mail list logo
