On 11/29/2016 06:49 AM, Oleksij Rempel wrote:
Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:
On 11/28/2016 08:33 PM, Oleksij Rempel wrote:
Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:
Am 28.11.2016 um 17:34 schrieb Kyle McMartin:
On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
wrote:
Hi Ben
On 29-11-2016 8:57, Johannes Berg wrote:
> On Tue, 2016-11-29 at 08:08 +0100, Rafał Miłecki wrote:
>> On 23 November 2016 at 11:25, Arend van Spriel
>> wrote:
>>>
>>> Introducing new source file for pno related functionality. Moving
>>> existing pno functions.
>>
>> Let me ask one basic question a
On 29-11-2016 10:10, IgorMitsyanko wrote:
> On 11/29/2016 06:49 AM, Oleksij Rempel wrote:
>> Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:
>>> On 11/28/2016 08:33 PM, Oleksij Rempel wrote:
Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:
[...]
>>> Oleksij, yes, that's correct, it includes en
Hi Oleksij,
I put 4 ar9271's on a 4 port hub into monitor mode for you and all
interfaces are simultaneously collecting packets. My cheap USB power
meter reads 4.37v@650mA between the hub and the host, so it's pushing
the limit but appears stable.
On Mon, Nov 28, 2016 at 7:34 AM, Oleksij Rempel
On 29-11-2016 8:37, Rafał Miłecki wrote:
> On 23 November 2016 at 11:25, Arend van Spriel
> wrote:
>> This patch series contains:
>> * cleanup of scheduled scan code.
>> * fix handling schedules scan results for newer chips.
>> * support for bcm43341 chipset with different chip id.
>> * support
On 11/29/2016 12:34 PM, Arend Van Spriel wrote:
On 29-11-2016 10:10, IgorMitsyanko wrote:
On 11/29/2016 06:49 AM, Oleksij Rempel wrote:
Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:
On 11/28/2016 08:33 PM, Oleksij Rempel wrote:
Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:
[...]
Oleksij,
On 29 November 2016 at 10:23, Arend Van Spriel
wrote:
> On 29-11-2016 8:57, Johannes Berg wrote:
>> On Tue, 2016-11-29 at 08:08 +0100, Rafał Miłecki wrote:
>>> On 23 November 2016 at 11:25, Arend van Spriel
>>> wrote:
Introducing new source file for pno related functionality. Moving
>>>
On 29 November 2016 at 10:58, Arend Van Spriel
wrote:
> On 29-11-2016 8:37, Rafał Miłecki wrote:
>> On 23 November 2016 at 11:25, Arend van Spriel
>> wrote:
>>> This patch series contains:
>>> * cleanup of scheduled scan code.
>>> * fix handling schedules scan results for newer chips.
>>> * suppo
On Wed, 2016-11-23 at 15:59 +0800, Chris Chiu wrote:
> ieee80211_iface_work() will check if sw scanning is in progress
> before handling block ack session. In our case, the RTL8821AE
> operate in station mode, when tx session expired, DELBA packet
> stuck during sw scanning and so do other data pac
On 29-11-2016 13:59, Johannes Berg wrote:
> On Wed, 2016-11-23 at 15:59 +0800, Chris Chiu wrote:
>> ieee80211_iface_work() will check if sw scanning is in progress
>> before handling block ack session. In our case, the RTL8821AE
>> operate in station mode, when tx session expired, DELBA packet
>>
From: Mohammed Shafi Shajakhan
During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.
During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called afte
On 11/28/2016 11:34 PM, Mohammed Shafi Shajakhan wrote:
Hi Ben,
On Mon, Nov 28, 2016 at 10:52:44AM -0800, Ben Greear wrote:
I ported forward my patch set to the 4.9 kernel, and I am seeing lockups fairly
often. As always, could be something I added locally, but in case someone sees
similar,
On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson wrote:
> [...]
>
>>> +
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW
Rafał Miłecki writes:
> On 29 November 2016 at 10:23, Arend Van Spriel
> wrote:
>> On 29-11-2016 8:57, Johannes Berg wrote:
>>> On Tue, 2016-11-29 at 08:08 +0100, Rafał Miłecki wrote:
On 23 November 2016 at 11:25, Arend van Spriel
wrote:
>
> Introducing new source file for pno
Hi Ben,
On Tue, Nov 29, 2016 at 06:50:33AM -0800, Ben Greear wrote:
>
>
> On 11/28/2016 11:34 PM, Mohammed Shafi Shajakhan wrote:
> >Hi Ben,
> >
> >On Mon, Nov 28, 2016 at 10:52:44AM -0800, Ben Greear wrote:
> >>I ported forward my patch set to the 4.9 kernel, and I am seeing lockups
> >>fairly
Hi Dave,
if there's still time here's one more patch to 3.9. I think this is good
to have in 3.9 as it fixes an issue where we were printing uninitialised
memory in mwifiex. I had this in wireless-drivers already for some time
as I was waiting for other fixes and nothing serious actually came up.
Am 29.11.2016 um 10:45 schrieb Anthony Romano:
> Hi Oleksij,
>
> I put 4 ar9271's on a 4 port hub into monitor mode for you and all
> interfaces are simultaneously collecting packets. My cheap USB power
> meter reads 4.37v@650mA between the hub and the host, so it's pushing
> the limit but appears
Kirtika Ruchandani wrote:
> Commit bec568ff5107 removed the last remaining usage of struct
> mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to
> mwifiex_del_virtual_intf().
> Compiling mwifiex/ with W=1 gives the following warning, fix it.
> mwifiex/main.c: In function ‘mwifiex_fw
Brian Norris wrote:
> Marvell Wifi PCIe modules don't always behave nicely for PCIe power
> management when their firmware hasn't been loaded, particularly after
> suspending the PCIe link one or more times. When this happens, we might
> end up spinning forever in this status-polling tight loop. L
Arend Van Spriel wrote:
> From: Franky Lin
>
> In rev6 of pcie host dongle interface protocol, host needs to maximum
> supported ring number from dongle shared memory and set up ring buffer
> and ring indices offset accordingly.
>
> Reviewed-by: Hante Meuleman
> Reviewed-by: Pieter-Paul Giesbe
Kirtika Ruchandani wrote:
> Initial commit cc0b88cf5ecf ([PATCH] Add adm8211 802.11b wireless driver)
> introduced variables mem_addr and io_addr in adm80211_probe() that are
> set but not used. Compiling with W=1 gives the following warnings,
> fix them.
>
> drivers/net/wireless/admtek/adm8211.c
Anthony Romano wrote:
> mt7601u_mac_stop_hw should stop polling the rxq once it remains empty
> but instead continues polling after the rxq status stays clear; bringing
> down the interface takes about six seconds from this alone.
>
> Speed up path by exiting rxq loop once status repeatedly polls
Larry Finger wrote:
> In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
> commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
> to use work queue"), an error was introduced in the power-save routines
> due to the fact that leaving PS was delayed by the u
Jiri Slaby wrote:
> This is what is in the laptop:
> 01:00.0 Network controller [0280]: Broadcom Limited BCM43142 802.11b/g/n
> [14e4:4365] (rev 01)
> Subsystem: Dell Device [1028:0018]
> Flags: bus master, fast devsel, latency 0, IRQ 18
> Memory at b040 (64-bit, non-p
On 29 November 2016 at 15:51, Rob Herring wrote:
> On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson wrote:
>> [...]
>>
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
Hello Matt,
On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren
> Cc: Ulf Hansson
> Cc: Mark Rutland
> Cc: Srinivas Kandagatla
> Signed-of
From: Ben Greear
Could be useful for debugging memory consumption issues,
and perhaps power-save as well.
Signed-off-by: Ben Greear
---
This is against 4.7.10+
net/mac80211/debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/net/mac80211/debugfs.c b/net/
From: Ben Greear
This fixes OOM when using pktgen to drive a wifi station at more than
the station can transmit. pktgen uses ndo_start_xmit instead of going
through the queue layer, so it will not back off when the queues are
stopped, and would thus cause packets to be added to the txqi->queue
u
From: Ben Greear
For non-station devices. This gives at least some useful
summary in some cases (especially when we know AP has only one
station attached, for instance).
Signed-off-by: Ben Greear
---
This is against 4.7.10+, applied to 4.4 and 4.9 for me as well.
net/mac80211/ethtool.c | 56
Is this something for stable? And if so, how far back should it be applied?
I'll add this patch to my 4.9 tree and test it...
Thanks,
Ben
On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhan
During firmware crash (or) user requested manual restart
the syste
When we try to transmit traffic (ping) between two meshed ath10k devices
running latest lede we keep experiencing ath10k firmware crashes. This
seems to only happen when running in 802.11n/ac mode but not in
802.11a/g mode. Also, from the station dumps it appears that management
traffic is flow
Hello, My name is Gloria C. Mackenzie, i have a Monetary Donation to make for
less privilege and yourself and your organization, am writing you with a
friend's email, please contact me on g_macken...@rogers.com
From: Ben Greear
These memory chunks are often used as 'swap' by the NIC,
so it will be both reading and writing to these areas.
This seems to fix errors like this on my x86-64 machine:
kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
DMAR:[fault reason 05] PT
From: Jes Sorensen
Hi,
This patch works around the issue with 8192eu and 8723bu devices not
being able to reconnect. It is still not clear why this fails, and
looking at rtlwifi it does issue the command for 8192ee and 8723be
devices.
Until we have a better idea of what is going on, I have comm
From: Jes Sorensen
The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
8723bu devices not being able to reconnect.
Reported-by: Barry Day
Signed-off-by: Jes Sorensen
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8
1 file changed, 8 insertions(+)
diff --
Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if
the found peer does not have any room to accept other peer. This causes
continuous connection trials.
Signed-off-by: Masashi Honma
---
net/mac80211/mesh_plink.c | 14 --
1 file changed, 8 insertions(+), 6 deletion
I have not seen this hang since adding this patch, so
hopefully it has resolved the problem.
Thanks,
Ben
On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhan
During firmware crash (or) user requested manual restart
the system gets into a soft lock up state be
On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
> wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren
From: Mohammed Shafi Shajakhan
During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.
During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called afte
On Tue, Nov 29, 2016 at 04:43:48PM -0800, Ben Greear wrote:
> I have not seen this hang since adding this patch, so
> hopefully it has resolved the problem.
thanks Ben ! I had updated the commit log with Fixes tag
https://patchwork.kernel.org/patch/9453609/
>
> On 11/29/2016 06:46 AM, Mohammed S
40 matches
Mail list logo