From: Andrei Otcheretianski andrei.otcheretian...@intel.com
Deliver up to 128 frames during SP instead of 8 if unlimited max SP
is specified during association.
Signed-off-by: Andrei Otcheretianski andrei.otcheretian...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
John,
Here are a few more fixes for 3.18, I hope that's not a problem.
johannes
---
The following changes since commit 11b2357d5dbce999803e9055f8c09829a8a87db4:
mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats (2014-10-20
16:37:01 +0200)
are available in the git repository
On Mon, 2014-11-03 at 20:06 +0200, Emmanuel Grumbach wrote:
From: Eran Harary eran.har...@intel.com
Maximum length of AMPDU that an STA can receive in VHT.
length = 2 ^ (13 + max_ampdu_length_exp) - 1.
Applied.
johannes
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Nov 4, 2014 at 2:10 PM, Emmanuel Grumbach
emmanuel.grumb...@intel.com wrote:
From: Andrei Otcheretianski andrei.otcheretian...@intel.com
Deliver up to 128 frames during SP instead of 8 if unlimited max SP
is specified during association.
Signed-off-by: Andrei Otcheretianski
On Tue, Nov 4, 2014 at 2:10 PM, Emmanuel Grumbach
emmanuel.grumb...@intel.com wrote:
From: Andrei Otcheretianski andrei.otcheretian...@intel.com
Deliver up to 128 frames during SP instead of 8 if unlimited max SP is
specified during association.
Signed-off-by: Andrei Otcheretianski
The spec doesn't require unlimited to be really unlimited and the AP decides
when to end the SP, so any value here is ok.
However for large traffic bursts increasing this value looks reasonable. Also
looks like some certification tests expect more frames to be delivered during
SP.
128 is still
On Mon, 2014-11-03 at 10:33 +0100, Rostislav Lisovy wrote:
The IEEE 802.11p amendment (already part of IEEE 802.11-2012)
specifies usage of 5 and 10 MHz wide channels in 5.9GHz band for
vehicular environment. All the 802.11p compliant devices should
be set to the newly added operation mode --
On Tue, Nov 4, 2014 at 2:53 PM, Otcheretianski, Andrei
andrei.otcheretian...@intel.com wrote:
The spec doesn't require unlimited to be really unlimited and the AP
decides when to end the SP, so any value here is ok.
However for large traffic bursts increasing this value looks reasonable. Also
On Tue, Nov 4, 2014 at 2:57 PM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
On Tue, Nov 4, 2014 at 2:53 PM, Otcheretianski, Andrei
andrei.otcheretian...@intel.com wrote:
The spec doesn't require unlimited to be really unlimited and the AP
decides when to end the SP, so any value here is
From: Andrei Otcheretianski andrei.otcheretian...@intel.com
Deliver up to 128 frames during SP instead of 8 if unlimited
max SP is specified during association.
8 was just an arbitrary value, so is 128 since unlimited can
be any number.
However for large traffic bursts, increasing this value
From: Eliad Peller el...@wizery.com
Drivers might want to know also when mac80211 has
completed reconfiguring after resume (e.g. in order
to know when frames can be passed to mac80211).
Rename restart_complete() to a more-generic reconfig_complete(),
and add a new enum to indicate the
On Tue, 2014-11-04 at 11:33 +0200, Emmanuel Grumbach wrote:
From: Andrei Otcheretianski andrei.otcheretian...@intel.com
Deliver up to 128 frames during SP instead of 8 if unlimited
max SP is specified during association.
8 was just an arbitrary value, so is 128 since unlimited can
be any
On Tue, 2014-11-04 at 11:43 +0200, Emmanuel Grumbach wrote:
From: Eliad Peller el...@wizery.com
Drivers might want to know also when mac80211 has
completed reconfiguring after resume (e.g. in order
to know when frames can be passed to mac80211).
Rename restart_complete() to a more-generic
Hi John,
This comes relatively late, but between other things I didn't get around
to it until now, sorry about that.
We have quite a bit of content, see below.
Let me know if there's any problem.
johannes
---
The following changes since commit 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e:
From: Avinash Patil pat...@marvell.com
We see this warning while starting mwifiex AP:
Unsupported RX-STBC, default to 2x2
This was happening because of wrong offset while copying HT
capabilities from BSS configuration of start_ap handler.
Signed-off-by: Amitkumar Karwar akar...@marvell.com
From: Avinash Patil pat...@marvell.com
It is observed that device sometimes sends BA setup requests for
broadcast mac address.
Its pointless to check for availablity of AMPDU/AMSDU streams
for broadcast mac address. This patch adds this check.
Signed-off-by: Amitkumar Karwar akar...@marvell.com
From: Avinash Patil pat...@marvell.com
This patch removes redundant data complete handler.
Signed-off-by: Avinash Patil pat...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Amitkumar Karwar akar...@marvell.com
---
drivers/net/wireless/mwifiex/main.h | 1 -
On some platforms, system goes out of memory during heavy
Rx traffic with our USB chipsets.
In case of SDIO/PCIe, after receiving 50 packets in Rx queue
we stop processing interrupts till packets pending fall below
low threshold i.e 20. We don't have similar logic for USB,
so if host platform is
Use the same ordering in the comments section as it
is in the structure below.
Signed-off-by: Rostislav Lisovy rostislav.lis...@fel.cvut.cz
---
include/net/cfg80211.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
On Tue, 2014-11-04 at 13:49 +0100, Rostislav Lisovy wrote:
Use the same ordering in the comments section as it
is in the structure below.
Well, I think I confused you :-)
The report from Fengguang's build bot was actually when there was no
documentation, and then I added it and I guess you
On Tue, 2014-11-04 at 10:25 +0100, Johannes Berg wrote:
On Mon, 2014-11-03 at 10:33 +0100, Rostislav Lisovy wrote:
The IEEE 802.11p amendment (already part of IEEE 802.11-2012)
specifies usage of 5 and 10 MHz wide channels in 5.9GHz band for
vehicular environment. All the 802.11p compliant
The original fix has been moved into a different
place in the code.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
Hi,
This patchset unifies rx path. Instead of
branching for A-MSDU and MSDU cases a single
codepath is introduced.
This yields:
textdata bss dec hex filename
14068 0 0 1406836f4 before/htt_rx.o
13308 3 0 1331133ff after/htt_rx.o
I
Make the rx_confused be handled by the rx
indication handlers instead of the buffer popping
function.
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff
On 11/04/14 12:57, Amitkumar Karwar wrote:
From: Avinash Patilpat...@marvell.com
It is observed that device sometimes sends BA setup requests for
broadcast mac address.
Its pointless to check for availablity of AMPDU/AMSDU streams
for broadcast mac address. This patch adds this check.
Maybe
Hi,
the only reason why nobody noticed is that the iw tool does not even
check the cmd field of the kernel replies it process. I wonder if iw
should check the value, just to make sure bugs like this are easier to
detect.
Henning Rogge
On Tue, Nov 4, 2014 at 4:37 PM, Johannes Berg
On Tue, 2014-11-04 at 16:56 +0100, Henning Rogge wrote:
Hi,
the only reason why nobody noticed is that the iw tool does not even
check the cmd field of the kernel replies it process. I wonder if iw
should check the value, just to make sure bugs like this are easier to
detect.
It doesn't
Hi Arend,
Thanks for your review,
Yes; current description may be confusing. I will send v2 with correct patch
description.
Thanks,
Avinash
From: Arend van Spriel [ar...@broadcom.com]
Sent: Tuesday, November 04, 2014 8:52 PM
To: Amitkumar Karwar
Cc:
On Tue, 2014-11-04 at 13:37 -0500, C. McPherson wrote:
Hello all:
I was just trying to use the latest stable backports-3.18-rc1-1 and I
noticed that there is no longer structure members in the
ieee80211_rx_status structure for Vendor namespace information? In my
backports 3.14 version I
On 09/23/2014 02:17 PM, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
When re-associating a station, the nss was set back to
maximum value even if user had configured small number
of tx chains. So, pay attention to user's config in
this case as well.
Looks like
Thanks so much for the info Johannes. I did notice that rx_status was
getting full. I'll go ahead and put it in skb-data, that's a good idea.
Clyde
On 11/04/2014 02:47 PM, Johannes Berg wrote:
On Tue, 2014-11-04 at 13:37 -0500, C. McPherson wrote:
Hello all:
I was just trying to use the
On Tue, Nov 04, 2014 at 09:57:21AM +0100, Johannes Berg wrote:
John,
Here are a few more fixes for 3.18, I hope that's not a problem.
johannes
---
The following changes since commit 11b2357d5dbce999803e9055f8c09829a8a87db4:
mac80211: minstrels: fix buffer overflow in HT debugfs
Rajkumar Manoharan rmano...@qti.qualcomm.com writes:
On Tue, Nov 04, 2014 at 01:34:37AM +0200, Kalle Valo wrote:
Rajkumar Manoharan rmano...@qti.qualcomm.com writes:
For packet log, the transmitted frame 802.11 header alone is sufficient.
Recording entire packet is also consuming lot of
On Wed, Oct 22, 2014 at 11:37 PM, Arik Nemtsov a...@wizery.com wrote:
Allow setting bandwidth related regulatory flags. These flags are mapped
to the corresponding channel flags in the specified range.
Make sure the new flags are consulted when calculating the maximum
bandwidth allowed by a
On Wed, Oct 22, 2014 at 11:37 PM, Arik Nemtsov a...@wizery.com wrote:
+static bool reg_wdev_chan_valid(struct wiphy *wiphy, struct wireless_dev
*wdev)
+{
+ struct ieee80211_channel *ch;
+ struct cfg80211_chan_def chandef;
+ struct cfg80211_registered_device *rdev =
On Wed, Oct 22, 2014 at 11:37 PM, Arik Nemtsov a...@wizery.com wrote:
cfg80211: allow wiphy specific regdomain management
This guy never made it to my inbox.
Luis
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
On Wed, Oct 22, 2014 at 11:37 PM, Arik Nemtsov a...@wizery.com wrote:
+ * @NL80211_ATTR_WIPHY_SELF_MANAGED_REG: flag attribute indicating the
+ * regulatory information came from the driver and not from the global
+ * cfg80211 regulatory domain information.
Awesome, can you also add
From: Avinash Patil pat...@marvell.com
This patch adds RX workqueue support for USB interfaces.
Currently rx_pending is applicable for cmd/events and Rx
data in USB interface. Let's use it only for Rx data.
Signed-off-by: Avinash Patil pat...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
On some platforms, system goes out of memory during heavy
Rx traffic with our USB chipsets.
In case of SDIO/PCIe, after receiving 50 packets in Rx queue
we stop processing interrupts till packets pending fall below
low threshold i.e 20. We don't have similar logic for USB,
so if host platform is
From: Avinash Patil pat...@marvell.com
This patch removes redundant data complete handler.
Signed-off-by: Avinash Patil pat...@marvell.com
Signed-off-by: Cathy Luo c...@marvell.com
Signed-off-by: Amitkumar Karwar akar...@marvell.com
---
drivers/net/wireless/mwifiex/main.h | 1 -
From: Avinash Patil pat...@marvell.com
It is observed that device sometimes sends BA setup requests for
broadcast mac address.
This patch adds a check to avoid checking availability of
AMPDU/AMSDU streams for broadcast mac address.
Signed-off-by: Amitkumar Karwar akar...@marvell.com
From: Avinash Patil pat...@marvell.com
We see this warning while starting mwifiex AP:
Unsupported RX-STBC, default to 2x2
This was happening because of wrong offset while copying HT
capabilities from BSS configuration of start_ap handler.
Signed-off-by: Amitkumar Karwar akar...@marvell.com
On Wed, Nov 05, 2014 at 05:04:29PM +0530, Amitkumar Karwar wrote:
On some platforms, system goes out of memory during heavy
Rx traffic with our USB chipsets.
In case of SDIO/PCIe, after receiving 50 packets in Rx queue
we stop processing interrupts till packets pending fall below
low
43 matches
Mail list logo
