From: Haim Dreyfuss
Last EBS status wasn't set to success in the initialization, which
caused the first scan to be without EBS. Fix that.
When EBS is not enabled by the driver, the FW still sends ebs_status success,
which can override EBS failure state. Consider only EBS failures, to avoid
such
From: Arik Nemtsov
During out-of-channel activities (e.g. scan) TDLS ch-switch responses from
a peer are kept in FW. These packets arrive only after the out-of-channel
activity is complete, which can be in the order of several seconds.
Since TDLS ch-sw has no dialog-token-like mechanism for dist
From: Ilan Peer
Use the chanel hw_value and not the center frequency when
building channel array for scan_config_cmd.
Signed-off-by: Ilan Peer
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Arik Nemtsov
Add a response-received state and add more limits on allowed requests
in each state of the connection. Previously ch-switch requests from
other peers could interrupt an outgoing active ch-switch. Also stale
packets from the current peer could disrupt the channel switch state.
From: Haim Dreyfuss
Enable EBS on one shot scans if supported by FW.
Signed-off-by: Haim Dreyfuss
Reviewed-by: Alexander Bondar
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/scan.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/
This watchdog allows to monitor the transmit queues. When a
queue doesn't progress for a too long time, a timer fires
and then, debug data can be collected.
This watchdog has never been enabled on dvm controlled
devices, so don't enable it there.
In order to have it running on mvm controlled device
Different queue can have different behavior. While it can be
unacceptable for a certain queue to be stuck for 2 seconds
(e.g. the command queue), it can happen that another queue
will stay stuck for even longer (a queue servicing a power
saving client in GO).
The op_mode can even make the timeout b
From: Luciano Coelho
When iwl_mvm_power_update_mac() is called, we have already added the
mac context, so if this call fails we should remove the mac.
CC: [3.15+]
Fixes: commit e5e7aa8e2561 ('iwlwifi: mvm: refactor power code')
Signed-off-by: Luciano Coelho
Reviewed-by: Johannes Berg
Signed-o
From: Johannes Berg
The quota threshold should be reduced to 4 to update the
firmware more frequently.
Signed-off-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/constants.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net
-9.ucode doesn't know the command SHARED_MEM_CFG yet.
Fixes: 04fd2c28226f ("iwlwifi: mvm: add rxf and txf to dump data")
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/fw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/m
From: Johannes Berg
There's really no reason to pad out the field with spaces at the
end of the line - they're practically invisible there anyway.
Signed-off-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/utils.c | 2 +-
1 file changed, 1 insertion(+),
The base address of the scheduler in the device's memory
(SRAM) comes from two different sources. The periphery
register and the alive notification from the firmware.
We have a check in iwl_pcie_tx_start that ensures that
they are the same.
When we resume from WoWLAN, the firmware may have crashed
Some devices have 31 TFD queues. Don't enable it yet since
there are still issues with it, but at least prepare the
code for it. There was a bug in the read pointer assignment,
fix that. Also, move the inline functions to iwl-scd.h which
is the right place.
Reviewed-by: Johannes Berg
Signed-off-b
From: Eyal Shapira
VHT Beamformer (BFER) will be used if the peer supports it
and there's a benefit to use it vs. STBC or SISO.
The driver now tells the FW whether BFER and/or STBC are
allowed but the FW will make the decision to use either
or stick to SISO on its own.
BFER is limited to a single
From: Luciano Coelho
We don't really need to use different mac colors when adding mac
contexts, because they're not used anywhere. In fact, the firmware
doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401
when we reach that.
Remove the color increment to use always zero and a
From: Eyal Shapira
In certain testing scenarios we'd like to force a decision
between STBC/BFER/SISO. In the normal scenario this decision
is done by the FW. Enable this option vis debugfs.
Signed-off-by: Eyal Shapira
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/ne
Printing all the scratch data of the TFDs of that queue is
useless and stuffed the kernel log with data. Remove that.
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/pcie/tx.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wirel
From: Luciano Coelho
If we don't want to restart the firmware, don't reprobe either in case
of a failure during reconfiguration. This allows us to debug failures
in the reconfig flow as well.
Signed-off-by: Luciano Coelho
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drive
IWL_UCODE_TLV_API_SCD_CFG is a new API and hence, check if
enabled in the correct field.
Fixes: 0294d9eece86 ("iwlwifi: mvm: let the firmware configure the scheduler")
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Hi Kalle,
Here is probably the last pull request for 3.20. Details below.
Since it is probably too late to send patches for 3.19, There are a few
patches here that are tagged for stable.
Please let me know if you have issues!
The following changes since commit 0b83795a110248db8f8e7c289a27b3b71b0
On Mon, 2015-02-02 at 10:52 -0800, Eric Dumazet wrote:
> It seems to break ACK clocking badly (linux stack has a somewhat buggy
> tcp_tso_should_defer(), which relies on ACK being received smoothly, as
> no timer is setup to split the TSO packet.)
Following patch might help the TSO split defer lo
On 02/02/2015 05:24 PM, Ken D'Ambrosio wrote:
Hi, all. Just got a new Thinkpad, and needless to say, tried to fire it up on
the network. Ubuntu 14.04 didn't have the driver, so I tried 14.10, which did.
I thought I was good until I tried to connect; the laptop would see all the
advertised WAPs,
Hi Florian,
Very appreciate your explanation in detail.
Regards,
Peter
On 02/02/2015 03:25 PM, Florian Fainelli wrote:
On 02/02/15 14:06, Peter Oh wrote:
On 02/02/2015 11:47 AM, Johannes Berg wrote:
On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote:
On 02/02/2015 11:22 AM, Johannes Berg wrot
Hi, all. Just got a new Thinkpad, and needless to say, tried to fire it
up on the network. Ubuntu 14.04 didn't have the driver, so I tried
14.10, which did. I thought I was good until I tried to connect; the
laptop would see all the advertised WAPs, but wouldn't connect to any of
them (inclu
On Mon, 2 Feb 2015, Avery Pennarun wrote:
On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman wrote:
On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote:
While there is definitely some work to be done in handoff, it seems
like there are some find implementations of this already in existence.
Sev
On 02/02/15 14:06, Peter Oh wrote:
>
> On 02/02/2015 11:47 AM, Johannes Berg wrote:
>> On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote:
>>> On 02/02/2015 11:22 AM, Johannes Berg wrote:
>> You basically have the following sequence:
>>
>> iowrite()
>> ioread()
>>
>> If you
On Mon, 2015-02-02 at 13:25 -0800, Ben Greear wrote:
> It is a big throughput win to have fewer TCP ack packets on
> wireless since it is a half-duplex environment. Is there anything
> we could improve so that we can have fewer acks and still get
> good tcp stack behaviour?
First apply TCP stret
On 02/02/2015 02:26 PM, Adrian Chadd wrote:
On 30 January 2015 at 18:06, Sujith Manoharan wrote:
Peter Oh wrote:
Please refer the email thread that I mentioned about other architectures.
(dsb is for ARM and other platforms have the equivalent instruction such
as sfence, sync, mf, and dcs).
O
On 02/02/2015 11:45 PM, Sven-Haegar Koch wrote:
Aren't they now all available as part of
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
Yes, all should be there as well, I guess. I didn't switch to that repo
yet because:
- they're not the same *.tgz files (with the
On Mon, 2 Feb 2015, Vladimír Čunát wrote:
> the URLs to iwlwifi firmware tarballs are broken.
> https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi
>
> Is that a temporary problem? I could find no mirrors for some of the files.
> (Besides, I found that nixos.org isn't the only user of those
On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman wrote:
> On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote:
>> While there is definitely some work to be done in handoff, it seems
>> like there are some find implementations of this already in existence.
>> Several brands of "enterprise access po
On 30 January 2015 at 18:06, Sujith Manoharan wrote:
> Peter Oh wrote:
>> Please refer the email thread that I mentioned about other architectures.
>> (dsb is for ARM and other platforms have the equivalent instruction such
>> as sfence, sync, mf, and dcs).
>
> Ok.
>
>> Also the patch is updated w
On 02/02/2015 11:47 AM, Johannes Berg wrote:
On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote:
On 02/02/2015 11:22 AM, Johannes Berg wrote:
You basically have the following sequence:
iowrite()
ioread()
If you look, you'll see that iowrite() is actually done (or should
be,
or perhaps with
Hello,
the URLs to iwlwifi firmware tarballs are broken.
https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi
Is that a temporary problem? I could find no mirrors for some of the
files. (Besides, I found that nixos.org isn't the only user of those URLs.)
Please, CC me with replies.
Tha
On 02/02/2015 10:52 AM, Eric Dumazet wrote:
> On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote:
>
>> While testing I've had my internal GRO patch for ath10k and no stretch
>> ack patches.
>
> Thanks for the data, I took a look at it.
>
> I am afraid this GRO patch might be the problem.
>
On Mon, Feb 2, 2015 at 9:56 PM, Gerlof Fokkema wrote:
>
> Dear Emmanuel,
>
> I have compiled and experimented with the kernel from this specific commit.
> While I don't get any crash logs from iwlmvm anymore, network performance is
> still truly horrible.
>
> After connecting the WiFi connection
Timeout was scheduled only in case CRDA was called due to user hints,
but was not scheduled for other cases. This can result in regulatory
hint processing getting stuck in case that there is no CRDA configured.
Change this by scheduling a timeout every time CRDA is called. In
addition, in restore_
As the operating environment of a device can change, add
API for user space to indicate a change of indoor settings.
In addition modify the handling of the indoor processing as
follows:
1. Directly update the indoor setting without wrapping it as a
regulatory request.
2. Track the socket on whi
On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote:
> On 02/02/2015 11:22 AM, Johannes Berg wrote:
> >>> You basically have the following sequence:
> >>>
> >>> iowrite()
> >>> ioread()
> >>>
> >>> If you look, you'll see that iowrite() is actually done (or should be,
> >>> or perhaps with appropriat
On 02/02/2015 11:22 AM, Johannes Berg wrote:
You basically have the following sequence:
iowrite()
ioread()
If you look, you'll see that iowrite() is actually done (or should be,
or perhaps with appropriate syncs) on an uncached mapping.
since it's mmio, iowrite will be map to write, not out w
> > You basically have the following sequence:
> >
> > iowrite()
> > ioread()
> >
> > If you look, you'll see that iowrite() is actually done (or should be,
> > or perhaps with appropriate syncs) on an uncached mapping.
> since it's mmio, iowrite will be map to write, not out which is cached
> ma
On 02/02/2015 10:54 AM, Johannes Berg wrote:
On Mon, 2015-02-02 at 09:33 -0800, Peter Oh wrote:
The code (as it is before your patch) implies that it's trying to make
sure that before it continues, any previous writes to the PCIe
device's
registers are posted. The only way to ensure that is
On Mon, 2015-02-02 at 09:33 -0800, Peter Oh wrote:
> > The code (as it is before your patch) implies that it's trying to make
> > sure that before it continues, any previous writes to the PCIe device's
> > registers are posted. The only way to ensure that is to do a read to the
> > registers, as t
On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote:
> While testing I've had my internal GRO patch for ath10k and no stretch
> ack patches.
Thanks for the data, I took a look at it.
I am afraid this GRO patch might be the problem.
It seems to break ACK clocking badly (linux stack has a some
On 02/02/2015 05:02 AM, Johannes Berg wrote:
On Fri, 2015-01-30 at 14:53 -0800, Peter Oh wrote:
I admit that I/O ordering and posted write are looked different in
theory and at glance since posted write could be related cache
invalidate.
But wmb are still related to both.
As I addressed wmb
On 01/30/2015 06:06 PM, Sujith Manoharan wrote:
Peter Oh wrote:
Please refer the email thread that I mentioned about other
architectures.
(dsb is for ARM and other platforms have the equivalent instruction such
as sfence, sync, mf, and dcs).
Ok.
Also the patch is updated with 2nd patch set
On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote:
> On Sun, Feb 1, 2015 at 9:43 AM, wrote:
>> Just to clarify, managing queueing in a single access point WiFi network is
>> only a small part of the problem of fixing the rapidly degrading performance
>> of WiFi based systems.
>
> Can you expl
On Sun, Feb 1, 2015 at 11:04 PM, Avery Pennarun wrote:
> On Sun, Feb 1, 2015 at 6:34 PM, Andrew McGregor wrote:
>> I missed one item in my list of potential improvements: the most braindead
>> thing 802.11 has to say about rates is that broadcast and multicast packets
>> should be sent at 'the lo
Fellow netheads:
Schedule:
==
The schedule is out. It is currently a graphic image, but we are
working on a proper non-graphic rendered clickable version.
https://www.netdev01.org/schedule
Registration:
==
There was a glitch in the regist
On Fri, 2015-01-30 at 14:53 -0800, Peter Oh wrote:
> I admit that I/O ordering and posted write are looked different in
> theory and at glance since posted write could be related cache invalidate.
> But wmb are still related to both.
> As I addressed wmb uses dsb (in arm arch) and here is the des
From: Sujith Manoharan
This patch addresses several issues with the
ath9k_hw_wow_enable() routine:
* The usage of set/clr variables is removed. Writing
the required values to registers is cleaner.
* The shift value of 28 for the contention window field
in AR_WOW_PATTERN is incorrect, change
From: Sujith Manoharan
Chips in the AR9003 family have a second TSF, which
needs to be cleared when putting the card to
sleep.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 9 +
drivers/net/wireless/ath/ath9k/reg.h| 2 ++
2 files changed, 11
From: Sujith Manoharan
Set the transmit rate for the keep-alive frames
as 1M/CCK when the current channel is in the
2GHz band.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wi
From: Sujith Manoharan
Setting the required configuration in the PCIE
WorkAround register needs to be done after all the
WoW parameters have been set.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 39 -
1 file changed, 22 insertio
From: Sujith Manoharan
Since the number of user patterns is higher for
newer chips, make sure that this is registered
during initialization.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/wow.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --
From: Sujith Manoharan
Newer chips like WB222, WB335 support more than
8 user-configurable patterns. This patch adds
support for it by setting up the correct HW
registers.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 48 +
driver
From: Sujith Manoharan
ath9k patches for -next.
Sujith Manoharan (6):
ath9k: Add support for more WOW patterns
ath9k: Register correct WOW details with mac80211
ath9k: Fix issues with WoW enable
ath9k: Program AR_WA correctly
ath9k: Clear TSF2 properly
ath9k: Choose correct rate for
On 30 January 2015 at 15:40, Eric Dumazet wrote:
> On Fri, 2015-01-30 at 14:39 +0100, Michal Kazior wrote:
>
>> I've briefly tried playing with this knob to no avail unfortunately. I
>> tried 256K, 1M - it didn't improve TCP performance. When I tried to
>> make it smaller (e.g. 16K) the traffic dr
On Fri, Jan 30, 2015 at 11:36 AM, Joe Perches wrote:
> Might be better with a const char * use
Yeah, could do that.
However, this is consistent with the rest of the code in iw, so should
be fine as is.
Thanks,
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
59 matches
Mail list logo
