Re: rt2800 maximum clients in access point mode

[Helmut Schaa]

On Tue, May 17, 2016 at 8:34 AM, Kalle Valo  wrote:
> Craig McQueen  writes:
>
>> What is the maximum number of clients that an rt2800 device can
>> support simultaneously while in access point mode?
>>
>> I've had a look through the Linux kernel code and searched online, but
>> haven't been able to find an answer so far.
>
> If you find the answer, please submit a patch to set
> wiphy->max_ap_assoc_sta in the driver. That way the limit is clearly
> visible and hostapd can make use of it.

As far as I remember, rt2800 has a limited key table (222 entries
according to the comments in the code).
Adding more STAs worked fine for me last time I tried (couple of years
ago). In that
case rt2800 should fall back to software crypto.

Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath9k: Fix symbol overlap window for half/quarter channels

[Helmut Schaa]

Since commit cd6cfd7311a385144a2f9c74f692ae2df3ae033f
"ath9k: do not set half/quarter channel flags in AR_PHY_MODE" the
condition "rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF)" would
never evaluate to true.

Fix this by using the available IS_CHAN_HALF_RATE and IS_CHAN_QUARTER_RATE
marcros instead.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
Cc: Felix Fietkau <n...@openwrt.org>
---
Just stumbled over that piece of code while looking into TX99, so
this is only compile-tested.

Felix, can you please confirm if this is correct or if removing
the whole block would be better?

Thanks,
Helmut

 drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 81ab3ca..ae304355 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1010,7 +1010,7 @@ static void ar9003_hw_set_rfmode(struct ath_hw *ah,
if (IS_CHAN_A_FAST_CLOCK(ah, chan))
rfMode |= (AR_PHY_MODE_DYNAMIC | AR_PHY_MODE_DYN_CCK_DISABLE);
 
-   if (rfMode & (AR_PHY_MODE_QUARTER | AR_PHY_MODE_HALF))
+   if (IS_CHAN_HALF_RATE(chan) || IS_CHAN_QUARTER_RATE(chan))
REG_RMW_FIELD(ah, AR_PHY_FRAME_CTL,
  AR_PHY_FRAME_CTL_CF_OVERLAP_WINDOW, 3);
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ath9k: Simplify ar9003_hw_tx99_set_txpower

[Helmut Schaa]

There's no need to keep the same for loop twice in the code.
Move the txpower cap before the loop to reduce code complexity.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
 drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 2f15cbc..81ab3ca 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1844,13 +1844,9 @@ static void ar9003_hw_tx99_set_txpower(struct ath_hw 
*ah, u8 txpower)
static u8 p_pwr_array[ar9300RateSize] = { 0 };
unsigned int i;
 
-   if (txpower <= MAX_RATE_POWER) {
-   for (i = 0; i < ar9300RateSize; i++)
-   p_pwr_array[i] = txpower;
-   } else {
-   for (i = 0; i < ar9300RateSize; i++)
-   p_pwr_array[i] = MAX_RATE_POWER;
-   }
+   txpower = txpower <= MAX_RATE_POWER ? txpower : MAX_RATE_POWER;
+   for (i = 0; i < ar9300RateSize; i++)
+   p_pwr_array[i] = txpower;
 
ar9003_hw_tx_power_regwrite(ah, p_pwr_array);
 }
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ath9k: reuse ar9003_hw_tx_power_regwrite for tx99 setup

[Helmut Schaa]

The same functionality as ar9003_hw_tx_power_regwrite is hardcoded in
ar9003_hw_tx99_set_txpower. Just reuse the existing ar9003_hw_tx_power_regwrite
for TX99 setup too.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c |  2 +-
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.h |  1 +
 drivers/net/wireless/ath/ath9k/ar9003_phy.c| 60 ++
 3 files changed, 5 insertions(+), 58 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c 
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index f680982..dec1a31 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -4402,7 +4402,7 @@ static void ar9003_hw_selfgen_tpc_txpower(struct ath_hw 
*ah,
 }
 
 /* Set tx power registers to array of values passed in */
-static int ar9003_hw_tx_power_regwrite(struct ath_hw *ah, u8 * pPwrArray)
+int ar9003_hw_tx_power_regwrite(struct ath_hw *ah, u8 * pPwrArray)
 {
 #define POW_SM(_r, _s) (((_r) & 0x3f) << (_s))
/* make sure forced gain is not set */
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h 
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 694ca2e..107bcfb 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -355,5 +355,6 @@ unsigned int ar9003_get_paprd_scale_factor(struct ath_hw 
*ah,
   struct ath9k_channel *chan);
 
 void ar9003_hw_internal_regulator_apply(struct ath_hw *ah);
+int ar9003_hw_tx_power_regwrite(struct ath_hw *ah, u8 * pPwrArray);
 
 #endif
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index be14a8e..2f15cbc 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -17,6 +17,7 @@
 #include 
 #include "hw.h"
 #include "ar9003_phy.h"
+#include "ar9003_eeprom.h"
 
 #define AR9300_OFDM_RATES  8
 #define AR9300_HT_SS_RATES 8
@@ -1840,7 +1841,7 @@ static void ar9003_hw_tx99_stop(struct ath_hw *ah)
 
 static void ar9003_hw_tx99_set_txpower(struct ath_hw *ah, u8 txpower)
 {
-   static s16 p_pwr_array[ar9300RateSize] = { 0 };
+   static u8 p_pwr_array[ar9300RateSize] = { 0 };
unsigned int i;
 
if (txpower <= MAX_RATE_POWER) {
@@ -1851,62 +1852,7 @@ static void ar9003_hw_tx99_set_txpower(struct ath_hw 
*ah, u8 txpower)
p_pwr_array[i] = MAX_RATE_POWER;
}
 
-   REG_WRITE(ah, 0xa458, 0);
-
-   REG_WRITE(ah, 0xa3c0,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24],  8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24],  0));
-   REG_WRITE(ah, 0xa3c4,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_54],  24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_48],  16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_36],   8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_6_24], 0));
-   REG_WRITE(ah, 0xa3c8,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L],  0));
-   REG_WRITE(ah, 0xa3cc,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_11S],   24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_11L],   16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_5S], 8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_LEGACY_1L_5L],  0));
-   REG_WRITE(ah, 0xa3d0,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_5],  24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_4],  16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_1_3_9_11_17_19], 8)|
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_0_8_16], 0));
-   REG_WRITE(ah, 0xa3d4,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_13], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_12], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_7],   8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_6],   0));
-   REG_WRITE(ah, 0xa3e4,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_21], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_20], 16) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_15],  8) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT20_14],  0));
-   REG_WRITE(ah, 0xa3e8,
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT40_23], 24) |
- ATH9K_POW_SM(p_pwr_array[ALL_TARGET_HT40_22], 16) |
-   

[PATCH 2/3] ath9k: Move TX99 config option under ath9k debugging

[Helmut Schaa]

Since ATH9K_TX99 depends on ATH9K_DEBUGFS anyway move it there
such that "make menuconfig" will indent TX99 support below ath9k
debugging.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
 drivers/net/wireless/ath/ath9k/Kconfig | 40 +-
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 40fa915..f68cb00 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -75,6 +75,26 @@ config ATH9K_STATION_STATISTICS
---help---
  This option enables detailed statistics for association stations.
 
+config ATH9K_TX99
+   bool "Atheros ath9k TX99 testing support"
+   depends on ATH9K_DEBUGFS && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ Say N. This should only be enabled on systems undergoing
+ certification testing and evaluation in a controlled environment.
+ Enabling this will only enable TX99 support, all other modes of
+ operation will be disabled.
+
+ TX99 support enables Specific Absorption Rate (SAR) testing.
+ SAR is the unit of measurement for the amount of radio frequency(RF)
+ absorbed by the body when using a wireless device. The RF exposure
+ limits used are expressed in the terms of SAR, which is a measure
+ of the electric and magnetic field strength and power density for
+ transmitters operating at frequencies from 300 kHz to 100 GHz.
+ Regulatory bodies around the world require that wireless device
+ be evaluated to meet the RF exposure limits set forth in the
+ governmental SAR regulations.
+
 config ATH9K_DFS_CERTIFIED
bool "Atheros DFS support for certified platforms"
depends on ATH9K && CFG80211_CERTIFICATION_ONUS
@@ -103,26 +123,6 @@ config ATH9K_DYNACK
  based on ACK frame RX timestamp, TX frame timestamp and frame
  duration
 
-config ATH9K_TX99
-   bool "Atheros ath9k TX99 testing support"
-   depends on ATH9K_DEBUGFS && CFG80211_CERTIFICATION_ONUS
-   default n
-   ---help---
- Say N. This should only be enabled on systems undergoing
- certification testing and evaluation in a controlled environment.
- Enabling this will only enable TX99 support, all other modes of
- operation will be disabled.
-
- TX99 support enables Specific Absorption Rate (SAR) testing.
- SAR is the unit of measurement for the amount of radio frequency(RF)
- absorbed by the body when using a wireless device. The RF exposure
- limits used are expressed in the terms of SAR, which is a measure
- of the electric and magnetic field strength and power density for
- transmitters operating at frequencies from 300 kHz to 100 GHz.
- Regulatory bodies around the world require that wireless device
- be evaluated to meet the RF exposure limits set forth in the
- governmental SAR regulations.
-
 config ATH9K_WOW
bool "Wake on Wireless LAN support (EXPERIMENTAL)"
depends on ATH9K && PM
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New firmware for RT2870

[Helmut Schaa]

On Wed, Mar 9, 2016 at 9:22 PM, Larry Finger  wrote:
> In https://bugzilla.kernel.org/show_bug.cgi?id=114151, the OP reports
> improved stability and performance for an RT5370 using a newer firmware that
> came with the driver CD. The logs show this to be version 0.36, whereas the
> version now in linux-firmware is version 0.29.
>
> I downloaded the firmware from b.k.o. It had very little effect on my
> no-name adapter with ID 148f:3070. It still gets ping losses of 10-15%.
>
> Should this new version be submitted to linux-firmware? Its provenance seems
> to be sketchy, but submission would likely be legal.

Version 0.36 can also be found in the vendor tarball on [1] even though it
references a different chip ...

So, in my opinion this should be safe from a legal point of view.

Helmut

[1] http://www.mediatek.com/en/downloads1/downloads/mt7612u/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] net: wireless: rt2x00: Space Required

[Helmut Schaa]

On Sat, Oct 17, 2015 at 11:11 PM, Paul McQuade <paulmcq...@gmail.com> wrote:
> Space needed before open parenthesis
>
> Signed-off-by: Paul McQuade <paulmcq...@gmail.com>

Looks valid to me.

Acked-by: Helmut Schaa <helmut.sc...@googlemail.com>

> ---
>  drivers/net/wireless/rt2x00/rt2x00debug.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00debug.c 
> b/drivers/net/wireless/rt2x00/rt2x00debug.c
> index 90fdb02..25ee3cb 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00debug.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00debug.c
> @@ -629,7 +629,7 @@ static struct dentry 
> *rt2x00debug_create_file_chipset(const char *name,
> data += sprintf(data, "register\tbase\twords\twordsize\n");
>  #define RT2X00DEBUGFS_SPRINTF_REGISTER(__name) \
>  {  \
> -   if(debug->__name.read)  \
> +   if (debug->__name.read) \
> data += sprintf(data, __stringify(__name)   \
> "\t%d\t%d\t%d\n",   \
> debug->__name.word_base,\
> @@ -699,7 +699,7 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
>
>  #define RT2X00DEBUGFS_CREATE_REGISTER_ENTRY(__intf, __name)  
>   \
>  ({   
>   \
> -   if(debug->__name.read) {  
>   \
> +   if (debug->__name.read) { 
>   \
> (__intf)->__name##_off_entry =
>   \
> debugfs_create_u32(__stringify(__name) "_offset", 
>   \
>S_IRUSR | S_IWUSR, 
>   \
> --
> 2.6.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] net: wireless: rt2x00: Pointer issue

[Helmut Schaa]

On Sat, Oct 17, 2015 at 11:06 PM, Paul McQuade <paulmcq...@gmail.com> wrote:
> Code Style: pointer is declared wrong
>
> Signed-off-by: Paul McQuade <paulmcq...@gmail.com>

Thanks for fixing this code style issue.

Acked-by: Helmut Schaa <helmut.sc...@googlemail.com>

> ---
>  drivers/net/wireless/rt2x00/rt2x00.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00.h 
> b/drivers/net/wireless/rt2x00/rt2x00.h
> index 6f8310a..b052e87 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00.h
> @@ -380,7 +380,7 @@ struct rt2x00_intf {
> atomic_t seqno;
>  };
>
> -static inline struct rt2x00_intf* vif_to_intf(struct ieee80211_vif *vif)
> +static inline struct rt2x00_intf *vif_to_intf(struct ieee80211_vif *vif)
>  {
> return (struct rt2x00_intf *)vif->drv_priv;
>  }
> @@ -507,7 +507,7 @@ struct rt2x00_sta {
> int wcid;
>  };
>
> -static inline struct rt2x00_sta* sta_to_rt2x00_sta(struct ieee80211_sta *sta)
> +static inline struct rt2x00_sta *sta_to_rt2x00_sta(struct ieee80211_sta *sta)
>  {
> return (struct rt2x00_sta *)sta->drv_priv;
>  }
> --
> 2.6.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: wireless: rt2x00: Fixed Spacing issues

[Helmut Schaa]

On Thu, Jan 21, 2016 at 5:56 PM, Helmut Schaa
<helmut.sc...@googlemail.com> wrote:
> On Sat, Oct 17, 2015 at 10:04 PM, Paul McQuade <paulmcq...@gmail.com> wrote:
>> Removed empty spaces before/after parenthesis
>>
>> Signed-off-by: Paul McQuade <paulmcq...@gmail.com>
>
> Just noticed these did not get applied by Kalle yet.

Kalle, can you fix up the path (ralink/rt2x00 instead of rt2x00) when applying?
Or would you prefer Paul to respin the whole code style cleanup series?

Thanks,
Helmut

> Looks good to me.
>
> Acked-by: Helmut Schaa <helmut.sc...@googlemail.com>
>
>> ---
>>  drivers/net/wireless/rt2x00/rt61pci.h | 20 ++--
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rt2x00/rt61pci.h 
>> b/drivers/net/wireless/rt2x00/rt61pci.h
>> index 1442075..ab86415 100644
>> --- a/drivers/net/wireless/rt2x00/rt61pci.h
>> +++ b/drivers/net/wireless/rt2x00/rt61pci.h
>> @@ -138,14 +138,14 @@
>>  #define PAIRWISE_TA_TABLE_BASE 0x1a00
>>
>>  #define SHARED_KEY_ENTRY(__idx) \
>> -   ( SHARED_KEY_TABLE_BASE + \
>> -   ((__idx) * sizeof(struct hw_key_entry)) )
>> +   (SHARED_KEY_TABLE_BASE + \
>> +   ((__idx) * sizeof(struct hw_key_entry)))
>>  #define PAIRWISE_KEY_ENTRY(__idx) \
>> -   ( PAIRWISE_KEY_TABLE_BASE + \
>> -   ((__idx) * sizeof(struct hw_key_entry)) )
>> +   (PAIRWISE_KEY_TABLE_BASE + \
>> +   ((__idx) * sizeof(struct hw_key_entry)))
>>  #define PAIRWISE_TA_ENTRY(__idx) \
>> -   ( PAIRWISE_TA_TABLE_BASE + \
>> -   ((__idx) * sizeof(struct hw_pairwise_ta_entry)) )
>> +   (PAIRWISE_TA_TABLE_BASE + \
>> +   ((__idx) * sizeof(struct hw_pairwise_ta_entry)))
>>
>>  struct hw_key_entry {
>> u8 key[16];
>> @@ -180,7 +180,7 @@ struct hw_pairwise_ta_entry {
>>  #define HW_BEACON_BASE30x2f00
>>
>>  #define HW_BEACON_OFFSET(__index) \
>> -   ( HW_BEACON_BASE0 + (__index * 0x0100) )
>> +   (HW_BEACON_BASE0 + (__index * 0x0100))
>>
>>  /*
>>   * HOST-MCU shared memory.
>> @@ -1287,9 +1287,9 @@ struct hw_pairwise_ta_entry {
>>  /*
>>   * DMA descriptor defines.
>>   */
>> -#define TXD_DESC_SIZE  ( 16 * sizeof(__le32) )
>> -#define TXINFO_SIZE( 6 * sizeof(__le32) )
>> -#define RXD_DESC_SIZE  ( 16 * sizeof(__le32) )
>> +#define TXD_DESC_SIZE  (16 * sizeof(__le32))
>> +#define TXINFO_SIZE(6 * sizeof(__le32))
>> +#define RXD_DESC_SIZE  (16 * sizeof(__le32))
>>
>>  /*
>>   * TX descriptor format for TX, PRIO and Beacon Ring.
>> --
>> 2.6.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] net: wireless: rt2x00: Space issue

[Helmut Schaa]

On Sat, Oct 17, 2015 at 11:06 PM, Paul McQuade <paulmcq...@gmail.com> wrote:
> Removed empty spaces before/after parenthesis
>
> Signed-off-by: Paul McQuade <paulmcq...@gmail.com>

Looks valid to me as well.

Acked-by: Helmut Schaa <helmut.sc...@googlemail.com>

> ---
>  drivers/net/wireless/rt2x00/rt2x00.h | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00.h 
> b/drivers/net/wireless/rt2x00/rt2x00.h
> index 3282ddb..6f8310a 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00.h
> @@ -107,7 +107,7 @@
>   * amount of bytes needed to move the data.
>   */
>  #define ALIGN_SIZE(__skb, __header) \
> -   (  ((unsigned long)((__skb)->data + (__header))) & 3 )
> +   (((unsigned long)((__skb)->data + (__header))) & 3)
>
>  /*
>   * Constants for extra TX headroom for alignment purposes.
> @@ -128,14 +128,14 @@
>  #define SLOT_TIME  20
>  #define SHORT_SLOT_TIME9
>  #define SIFS   10
> -#define PIFS   ( SIFS + SLOT_TIME )
> -#define SHORT_PIFS ( SIFS + SHORT_SLOT_TIME )
> -#define DIFS   ( PIFS + SLOT_TIME )
> -#define SHORT_DIFS ( SHORT_PIFS + SHORT_SLOT_TIME )
> -#define EIFS   ( SIFS + DIFS + \
> - GET_DURATION(IEEE80211_HEADER + ACK_SIZE, 
> 10) )
> -#define SHORT_EIFS ( SIFS + SHORT_DIFS + \
> - GET_DURATION(IEEE80211_HEADER + ACK_SIZE, 
> 10) )
> +#define PIFS   (SIFS + SLOT_TIME)
> +#define SHORT_PIFS (SIFS + SHORT_SLOT_TIME)
> +#define DIFS   (PIFS + SLOT_TIME)
> +#define SHORT_DIFS (SHORT_PIFS + SHORT_SLOT_TIME)
> +#define EIFS   (SIFS + DIFS + \
> + GET_DURATION(IEEE80211_HEADER + ACK_SIZE, 
> 10))
> +#define SHORT_EIFS (SIFS + SHORT_DIFS + \
> + GET_DURATION(IEEE80211_HEADER + ACK_SIZE, 
> 10))
>
>  enum rt2x00_chip_intf {
> RT2X00_CHIP_INTF_PCI,
>
> --
> 2.6.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rt2x00pci: Disable memory-write-invalidate when the driver exits

[Helmut Schaa]

On Tue, Jan 5, 2016 at 2:27 AM, Jia-Ju Bai <baijiaju1...@163.com> wrote:
> On 01/05/2016 12:50 AM, Helmut Schaa wrote:
>>
>> On Mon, Jan 4, 2016 at 8:55 AM, Jia-Ju Bai<baijiaju1...@163.com>  wrote:
>>>
>>> The driver calls pci_set_mwi to enable memory-write-invalidate when it
>>> is initialized, but does not call pci_clear_mwi when it is removed. Many
>>> other drivers calls pci_clear_mwi when pci_set_mwi is called, such as
>>> r8169, 8139cp and e1000.
>>>
>>> This patch adds pci_clear_mwi in error handling and removal procedure,
>>> which can fix the problem.
>>>
>>> Signed-off-by: Jia-Ju Bai<baijiaju1...@163.com>
>>
>> Looks good to me.
>> Does this fix any actual issue?
>> If yes it might we worth to mention it in the commit message.
>> Helmut
>>
>
> Lacking pci_clear_mwi may cause a resource-release omission,
> but this omission may not cause obvious issues.
> For reliability, it is better to add pci_clear_mwi in the driver.
> Many other drivers do so, such as r8169, 8139cp and e1000.

Thanks for clarification, fine with me then.

Acked-by: Helmut Schaa <helmut.sc...@googlemail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] mac80211: Don't buffer non-bufferable MMPDUs

[Helmut Schaa]

Non-bufferable MMPDUs are sent out to STAs even while in PS mode
(for example probe responses). Applying filtered frame handling for
these doesn't seem to make much sense and will only create more
air utilization when the STA wakes up. Hence, apply filtered frame
handling only for bufferable MMPDUs.

Discovered while testing an old VOIP phone that started probing
for APs while in PS mode. The mac80211/ath9k AP where the STA is
associated would reply with a probe response but the phone sometimes
moved to a new channel already and couldn't ack the probe response
anymore. In that case mac80211 applied filtered frame handling
for the un-acked probe response.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---

Changes in v2: Check IEEE80211_TX_CTL_NO_PS_BUFFER instead of frame_control 
field

 net/mac80211/status.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 5bad05e..6101deb 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -51,6 +51,11 @@ static void ieee80211_handle_filtered_frame(struct 
ieee80211_local *local,
struct ieee80211_hdr *hdr = (void *)skb->data;
int ac;
 
+   if (info->flags & IEEE80211_TX_CTL_NO_PS_BUFFER) {
+   ieee80211_free_txskb(>hw, skb);
+   return;
+   }
+
/*
 * This skb 'survived' a round-trip through the driver, and
 * hopefully the driver didn't mangle it too badly. However,
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: Don't buffer non-bufferable MMPDUs

[Helmut Schaa]

Non-bufferable MMPDUs are sent out to STAs even while in PS mode
(for example probe responses). Applying filtered frame handling for
these doesn't seem to make much sense and will only create more
air utilization when the STA wakes up. Hence, apply filtered frame
handling only for bufferable MMPDUs.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
 net/mac80211/status.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 5bad05e..14bd53b 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -51,6 +51,12 @@ static void ieee80211_handle_filtered_frame(struct 
ieee80211_local *local,
struct ieee80211_hdr *hdr = (void *)skb->data;
int ac;
 
+   if (ieee80211_is_mgmt(hdr->frame_control) &&
+   !ieee80211_is_bufferable_mmpdu(hdr->frame_control)) {
+   ieee80211_free_txskb(>hw, skb);
+   return;
+   }
+
/*
 * This skb 'survived' a round-trip through the driver, and
 * hopefully the driver didn't mangle it too badly. However,
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Don't buffer non-bufferable MMPDUs

[Helmut Schaa]

On Tue, Jan 5, 2016 at 4:52 PM, Johannes Berg <johan...@sipsolutions.net> wrote:
> On Tue, 2016-01-05 at 16:43 +0100, Helmut Schaa wrote:
>
>> > That said, it obviously also points to a driver bug not treating
>> > these frames correctly, so you might want to investigate why you
>> > got here to start with!
>>
>> It was not the driver marking the frame as filtered but mac80211
>> itself in status.c:
>>
>> acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
>> if (!acked && test_sta_flag(sta, WLAN_STA_PS_STA)) {
>> /*
>>  * The STA is in power save mode, so assume
>>  * that this TX packet failed because of
>> that.
>>  */
>> ieee80211_handle_filtered_frame(local, sta,
>> skb);
>> rcu_read_unlock();
>> return;
>> }
>
> Ah, yes, ok. So the frame simply didn't go through, for whatever
> reason. Hopefully the driver actually transmitted it :)

Yep, saw it on the air.

It was a STA sending probe requests while in PS mode and jumping to a new
channel before receiving/acking all probe responses. Hence, a probe response
ended up in the filtered queue. And it was easy to reproduce with this specific
STA (some old voip phone).

>> However, I've put the code into ieee80211_handle_filtered_frame to
>> not grow ieee80211_tx_status even more :)
>>
>> If you prefer to add it here directly I'm fine to change it.
>>
>
> No, looks fine as is. I just misunderstood how we got here.

Ok, I'd still like to change to checking IEEE80211_TX_CTL_NO_PS_BUFFER
instead -> v2 follows.

Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Don't buffer non-bufferable MMPDUs

[Helmut Schaa]

On Tue, Jan 5, 2016 at 4:35 PM, Johannes Berg <johan...@sipsolutions.net> wrote:
> On Tue, 2016-01-05 at 15:37 +0100, Helmut Schaa wrote:
>> Non-bufferable MMPDUs are sent out to STAs even while in PS mode
>> (for example probe responses). Applying filtered frame handling for
>> these doesn't seem to make much sense and will only create more
>> air utilization when the STA wakes up. Hence, apply filtered frame
>> handling only for bufferable MMPDUs.
>>
>> Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
>> ---
>>  net/mac80211/status.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
>> index 5bad05e..14bd53b 100644
>> --- a/net/mac80211/status.c
>> +++ b/net/mac80211/status.c
>> @@ -51,6 +51,12 @@ static void ieee80211_handle_filtered_frame(struct
>> ieee80211_local *local,
>>   struct ieee80211_hdr *hdr = (void *)skb->data;
>>   int ac;
>>
>> + if (ieee80211_is_mgmt(hdr->frame_control) &&
>> + !ieee80211_is_bufferable_mmpdu(hdr->frame_control)) {
>> + ieee80211_free_txskb(>hw, skb);
>> + return;
>> + }
>>
> I don't really see a problem per se with this patch, but it seems that
> we could just check the flags instead? Perhaps we simply shouldn't
> apply buffering filtered frames here to frames that were already marked
> with IEEE80211_TX_CTL_NO_PS_BUFFER, since those frames shouldn't be
> filtered by the driver to start with.

Good point, that should make the check a bit nicer. I'll change that.

> That said, it obviously also points to a driver bug not treating these
> frames correctly, so you might want to investigate why you got here to
> start with!

It was not the driver marking the frame as filtered but mac80211
itself in status.c:

acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
if (!acked && test_sta_flag(sta, WLAN_STA_PS_STA)) {
/*
 * The STA is in power save mode, so assume
 * that this TX packet failed because of that.
 */
ieee80211_handle_filtered_frame(local, sta, skb);
rcu_read_unlock();
return;
}

However, I've put the code into ieee80211_handle_filtered_frame to
not grow ieee80211_tx_status even more :)

If you prefer to add it here directly I'm fine to change it.

Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rt2x00pci: Disable memory-write-invalidate when the driver exits

[Helmut Schaa]

On Mon, Jan 4, 2016 at 8:55 AM, Jia-Ju Bai  wrote:
> The driver calls pci_set_mwi to enable memory-write-invalidate when it
> is initialized, but does not call pci_clear_mwi when it is removed. Many
> other drivers calls pci_clear_mwi when pci_set_mwi is called, such as
> r8169, 8139cp and e1000.
>
> This patch adds pci_clear_mwi in error handling and removal procedure,
> which can fix the problem.
>
> Signed-off-by: Jia-Ju Bai 

Looks good to me.
Does this fix any actual issue?
If yes it might we worth to mention it in the commit message.
Helmut


> ---
>  drivers/net/wireless/rt2x00/rt2x00pci.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c 
> b/drivers/net/wireless/rt2x00/rt2x00pci.c
> index d93db4b..eb6dbcd 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
> @@ -149,6 +149,7 @@ exit_free_device:
> ieee80211_free_hw(hw);
>
>  exit_release_regions:
> +   pci_clear_mwi(pci_dev);
> pci_release_regions(pci_dev);
>
>  exit_disable_device:
> @@ -173,6 +174,7 @@ void rt2x00pci_remove(struct pci_dev *pci_dev)
> /*
>  * Free the PCI device data.
>  */
> +   pci_clear_mwi(pci_dev);
> pci_disable_device(pci_dev);
> pci_release_regions(pci_dev);
>  }
> --
> 1.7.9.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix oops in ieee80211_beacon_get_tim

[Helmut Schaa]

Christian Lamparter  schrieb:
>This patch fixes a crash which is triggered
>by __ieee80211_beacon_get returning NULL.

Ouch, thanks for catching this!
Helmut

>This causes sky_copy to crash later unless
>the hardware supports BEACON_TX_STATUS
>feature.
>
>Signed-off-by: Christian Lamparter 
>---
>"mac80211: Copy tx'ed beacons to monitor mode" added the skb_copy.
>There are few other possibilities to do this. This is just one.
>---
> net/mac80211/tx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
>index f7317a7..666e46b 100644
>--- a/net/mac80211/tx.c
>+++ b/net/mac80211/tx.c
>@@ -3530,6 +3530,9 @@ struct sk_buff *ieee80211_beacon_get_tim(struct
>ieee80211_hw *hw,
>   struct ieee80211_supported_band *sband;
>   int shift;
> 
>+  if (!bcn)
>+  return bcn;
>+
>   if (tim_offset)
>   *tim_offset = offs.tim_offset;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] mac80211: Copy tx'ed beacons to monitor mode

[Helmut Schaa]

When debugging wireless powersave issues on the AP side it's quite helpful
to see our own beacons that are transmitted by the hardware/driver. However,
this is not that easy since beacons don't pass through the regular TX queues.

Preferably drivers would call ieee80211_tx_status also for tx'ed beacons
but that's not always possible. Hence, just send a copy of each beacon
generated by ieee80211_beacon_get_tim to monitor devices when they are
getting fetched by the driver.

Also add a HW flag IEEE80211_HW_BEACON_TX_STATUS that can be used by
drivers to indicate that they report TX status for beacons.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---

Changes since RFC:
* don't send beacons to cooked monitors
* avoid assignment within if condition
* Introduce IEEE80211_HW_BEACON_TX_STATUS

Changes since v1:
* Invert logic to get shorter lines (<80 chars)

 include/net/mac80211.h |  4 
 net/mac80211/debugfs.c |  1 +
 net/mac80211/tx.c  | 16 
 3 files changed, 21 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e3314e5..b136ac5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1892,6 +1892,9 @@ struct ieee80211_txq {
  * @IEEE80211_HW_TDLS_WIDER_BW: The device/driver supports wider bandwidth
  * than then BSS bandwidth for a TDLS link on the base channel.
  *
+ * @IEEE80211_HW_BEACON_TX_STATUS: The device/driver provides TX status
+ * for sent beacons.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -1925,6 +1928,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_CLONED_SKBS,
IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS,
IEEE80211_HW_TDLS_WIDER_BW,
+   IEEE80211_HW_BEACON_TX_STATUS,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index ced6bf3..d55f5ba 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -123,6 +123,7 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 
1] = {
FLAG(SUPPORTS_CLONED_SKBS),
FLAG(SINGLE_SCAN_ON_ALL_BANDS),
FLAG(TDLS_WIDER_BW),
+   FLAG(BEACON_TX_STATUS),
 
/* keep last for the build bug below */
(void *)0x1
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 84e0e8c..e482f3e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3512,6 +3512,9 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
 {
struct ieee80211_mutable_offsets offs = {};
struct sk_buff *bcn = __ieee80211_beacon_get(hw, vif, , false);
+   struct sk_buff *copy;
+   struct ieee80211_supported_band *sband;
+   int shift;
 
if (tim_offset)
*tim_offset = offs.tim_offset;
@@ -3519,6 +3522,19 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
if (tim_length)
*tim_length = offs.tim_length;
 
+   if (ieee80211_hw_check(hw, BEACON_TX_STATUS) ||
+   !hw_to_local(hw)->monitors)
+   return bcn;
+
+   /* send a copy to monitor interfaces */
+   copy = skb_copy(bcn, GFP_ATOMIC);
+   if (!copy)
+   return bcn;
+
+   shift = ieee80211_vif_get_shift(vif);
+   sband = hw->wiphy->bands[ieee80211_get_sdata_band(vif_to_sdata(vif))];
+   ieee80211_tx_monitor(hw_to_local(hw), copy, sband, 1, shift, false);
+
return bcn;
 }
 EXPORT_SYMBOL(ieee80211_beacon_get_tim);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] mac80211: Split sending tx'ed frames to monitor interfaces into its own function

[Helmut Schaa]

This allows ieee80211_tx_monitor to be used directly for sending 802.11 frames
to all monitor interfaces.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
 net/mac80211/ieee80211_i.h |   3 ++
 net/mac80211/status.c  | 108 +
 2 files changed, 62 insertions(+), 49 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 6e52659..36552de 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1641,6 +1641,9 @@ void ieee80211_purge_tx_queue(struct ieee80211_hw *hw,
 struct sk_buff *
 ieee80211_build_data_template(struct ieee80211_sub_if_data *sdata,
  struct sk_buff *skb, u32 info_flags);
+void ieee80211_tx_monitor(struct ieee80211_local *local, struct sk_buff *skb,
+ struct ieee80211_supported_band *sband,
+ int retry_count, int shift, bool send_to_cooked);
 
 void ieee80211_check_fast_xmit(struct sta_info *sta);
 void ieee80211_check_fast_xmit_all(struct ieee80211_local *local);
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 8ba5832..98fd04c 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -668,16 +668,70 @@ void ieee80211_tx_status_noskb(struct ieee80211_hw *hw,
 }
 EXPORT_SYMBOL(ieee80211_tx_status_noskb);
 
-void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
+void ieee80211_tx_monitor(struct ieee80211_local *local, struct sk_buff *skb,
+ struct ieee80211_supported_band *sband,
+ int retry_count, int shift, bool send_to_cooked)
 {
struct sk_buff *skb2;
+   struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+   struct ieee80211_sub_if_data *sdata;
+   struct net_device *prev_dev = NULL;
+   int rtap_len;
+
+   /* send frame to monitor interfaces now */
+   rtap_len = ieee80211_tx_radiotap_len(info);
+   if (WARN_ON_ONCE(skb_headroom(skb) < rtap_len)) {
+   pr_err("ieee80211_tx_status: headroom too small\n");
+   dev_kfree_skb(skb);
+   return;
+   }
+   ieee80211_add_tx_radiotap_header(local, sband, skb, retry_count,
+rtap_len, shift);
+
+   /* XXX: is this sufficient for BPF? */
+   skb_set_mac_header(skb, 0);
+   skb->ip_summed = CHECKSUM_UNNECESSARY;
+   skb->pkt_type = PACKET_OTHERHOST;
+   skb->protocol = htons(ETH_P_802_2);
+   memset(skb->cb, 0, sizeof(skb->cb));
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, >interfaces, list) {
+   if (sdata->vif.type == NL80211_IFTYPE_MONITOR) {
+   if (!ieee80211_sdata_running(sdata))
+   continue;
+
+   if ((sdata->u.mntr_flags & MONITOR_FLAG_COOK_FRAMES) &&
+   !send_to_cooked)
+   continue;
+
+   if (prev_dev) {
+   skb2 = skb_clone(skb, GFP_ATOMIC);
+   if (skb2) {
+   skb2->dev = prev_dev;
+   netif_rx(skb2);
+   }
+   }
+
+   prev_dev = sdata->dev;
+   }
+   }
+   if (prev_dev) {
+   skb->dev = prev_dev;
+   netif_rx(skb);
+   skb = NULL;
+   }
+   rcu_read_unlock();
+   dev_kfree_skb(skb);
+}
+
+void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
+{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
__le16 fc;
struct ieee80211_supported_band *sband;
-   struct ieee80211_sub_if_data *sdata;
-   struct net_device *prev_dev = NULL;
struct sta_info *sta;
struct rhash_head *tmp;
int retry_count;
@@ -685,7 +739,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
bool send_to_cooked;
bool acked;
struct ieee80211_bar *bar;
-   int rtap_len;
int shift = 0;
int tid = IEEE80211_NUM_TIDS;
const struct bucket_table *tbl;
@@ -878,51 +931,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
return;
}
 
-   /* send frame to monitor interfaces now */
-   rtap_len = ieee80211_tx_radiotap_len(info);
-   if (WARN_ON_ONCE(skb_headroom(skb) < rtap_len)) {
-   pr_err("ieee80211_tx_status: headroom too small\n");
-   dev_kfree_skb(skb);
-   return;
-   }
-   ieee80211_add_tx_radiotap_header(local, sband, skb, retry_count,
-  

[PATCH 2/2] mac80211: Copy tx'ed beacons to monitor mode

[Helmut Schaa]

When debugging wireless powersave issues on the AP side it's quite helpful
to see our own beacons that are transmitted by the hardware/driver. However,
this is not that easy since beacons don't pass through the regular TX queues.

Preferably drivers would call ieee80211_tx_status also for tx'ed beacons
but that's not always possible. Hence, just send a copy of each beacon
generated by ieee80211_beacon_get_tim to monitor devices when they are
getting fetched by the driver.

Also add a HW flag IEEE80211_HW_BEACON_TX_STATUS that can be used by
drivers to indicate that they report TX status for beacons.

Signed-off-by: Helmut Schaa <helmut.sc...@googlemail.com>
---
Changes since RFC:
* don't send beacons to cooked monitors
* avoid assignment within if condition
* Introduce IEEE80211_HW_BEACON_TX_STATUS

 include/net/mac80211.h |  4 
 net/mac80211/debugfs.c |  1 +
 net/mac80211/tx.c  | 13 +
 3 files changed, 18 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e3314e5..b136ac5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1892,6 +1892,9 @@ struct ieee80211_txq {
  * @IEEE80211_HW_TDLS_WIDER_BW: The device/driver supports wider bandwidth
  * than then BSS bandwidth for a TDLS link on the base channel.
  *
+ * @IEEE80211_HW_BEACON_TX_STATUS: The device/driver provides TX status
+ * for sent beacons.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -1925,6 +1928,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_CLONED_SKBS,
IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS,
IEEE80211_HW_TDLS_WIDER_BW,
+   IEEE80211_HW_BEACON_TX_STATUS,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index ced6bf3..d55f5ba 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -123,6 +123,7 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 
1] = {
FLAG(SUPPORTS_CLONED_SKBS),
FLAG(SINGLE_SCAN_ON_ALL_BANDS),
FLAG(TDLS_WIDER_BW),
+   FLAG(BEACON_TX_STATUS),
 
/* keep last for the build bug below */
(void *)0x1
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 84e0e8c..88720cb 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3512,6 +3512,8 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
 {
struct ieee80211_mutable_offsets offs = {};
struct sk_buff *bcn = __ieee80211_beacon_get(hw, vif, , false);
+   struct ieee80211_supported_band *sband;
+   int shift;
 
if (tim_offset)
*tim_offset = offs.tim_offset;
@@ -3519,6 +3521,17 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
if (tim_length)
*tim_length = offs.tim_length;
 
+   /* send a copy to monitor interfaces */
+   if (!ieee80211_hw_check(hw, BEACON_TX_STATUS) &&
+   hw_to_local(hw)->monitors) {
+   struct sk_buff *copy = skb_copy(bcn, GFP_ATOMIC);
+   if (copy) {
+   shift = ieee80211_vif_get_shift(vif);
+   sband = 
hw->wiphy->bands[ieee80211_get_sdata_band(vif_to_sdata(vif))];
+   ieee80211_tx_monitor(hw_to_local(hw), copy, sband, 1, 
shift, false);
+   }
+   }
+
return bcn;
 }
 EXPORT_SYMBOL(ieee80211_beacon_get_tim);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 1/2] mac80211: Split sending tx'ed frames to monitor interfaces into its own function

[Helmut Schaa]

This allows ieee80211_tx_monitor to be used directly for sending 802.11 frames
to all monitor interfaces.
---
 net/mac80211/ieee80211_i.h |   3 ++
 net/mac80211/status.c  | 108 +
 2 files changed, 62 insertions(+), 49 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 6e52659..36552de 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1641,6 +1641,9 @@ void ieee80211_purge_tx_queue(struct ieee80211_hw *hw,
 struct sk_buff *
 ieee80211_build_data_template(struct ieee80211_sub_if_data *sdata,
  struct sk_buff *skb, u32 info_flags);
+void ieee80211_tx_monitor(struct ieee80211_local *local, struct sk_buff *skb,
+ struct ieee80211_supported_band *sband,
+ int retry_count, int shift, bool send_to_cooked);
 
 void ieee80211_check_fast_xmit(struct sta_info *sta);
 void ieee80211_check_fast_xmit_all(struct ieee80211_local *local);
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 8ba5832..98fd04c 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -668,16 +668,70 @@ void ieee80211_tx_status_noskb(struct ieee80211_hw *hw,
 }
 EXPORT_SYMBOL(ieee80211_tx_status_noskb);
 
-void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
+void ieee80211_tx_monitor(struct ieee80211_local *local, struct sk_buff *skb,
+ struct ieee80211_supported_band *sband,
+ int retry_count, int shift, bool send_to_cooked)
 {
struct sk_buff *skb2;
+   struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+   struct ieee80211_sub_if_data *sdata;
+   struct net_device *prev_dev = NULL;
+   int rtap_len;
+
+   /* send frame to monitor interfaces now */
+   rtap_len = ieee80211_tx_radiotap_len(info);
+   if (WARN_ON_ONCE(skb_headroom(skb) < rtap_len)) {
+   pr_err("ieee80211_tx_status: headroom too small\n");
+   dev_kfree_skb(skb);
+   return;
+   }
+   ieee80211_add_tx_radiotap_header(local, sband, skb, retry_count,
+rtap_len, shift);
+
+   /* XXX: is this sufficient for BPF? */
+   skb_set_mac_header(skb, 0);
+   skb->ip_summed = CHECKSUM_UNNECESSARY;
+   skb->pkt_type = PACKET_OTHERHOST;
+   skb->protocol = htons(ETH_P_802_2);
+   memset(skb->cb, 0, sizeof(skb->cb));
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, >interfaces, list) {
+   if (sdata->vif.type == NL80211_IFTYPE_MONITOR) {
+   if (!ieee80211_sdata_running(sdata))
+   continue;
+
+   if ((sdata->u.mntr_flags & MONITOR_FLAG_COOK_FRAMES) &&
+   !send_to_cooked)
+   continue;
+
+   if (prev_dev) {
+   skb2 = skb_clone(skb, GFP_ATOMIC);
+   if (skb2) {
+   skb2->dev = prev_dev;
+   netif_rx(skb2);
+   }
+   }
+
+   prev_dev = sdata->dev;
+   }
+   }
+   if (prev_dev) {
+   skb->dev = prev_dev;
+   netif_rx(skb);
+   skb = NULL;
+   }
+   rcu_read_unlock();
+   dev_kfree_skb(skb);
+}
+
+void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
+{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
__le16 fc;
struct ieee80211_supported_band *sband;
-   struct ieee80211_sub_if_data *sdata;
-   struct net_device *prev_dev = NULL;
struct sta_info *sta;
struct rhash_head *tmp;
int retry_count;
@@ -685,7 +739,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
bool send_to_cooked;
bool acked;
struct ieee80211_bar *bar;
-   int rtap_len;
int shift = 0;
int tid = IEEE80211_NUM_TIDS;
const struct bucket_table *tbl;
@@ -878,51 +931,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
return;
}
 
-   /* send frame to monitor interfaces now */
-   rtap_len = ieee80211_tx_radiotap_len(info);
-   if (WARN_ON_ONCE(skb_headroom(skb) < rtap_len)) {
-   pr_err("ieee80211_tx_status: headroom too small\n");
-   dev_kfree_skb(skb);
-   return;
-   }
-   ieee80211_add_tx_radiotap_header(local, sband, skb, retry_count,
-rtap_len, shift);
-
-   /* XXX: is this sufficient for BPF? */
-   skb_set_mac_header(skb, 0);
-   skb->ip_summed = 

[RFC 2/2] mac80211: Copy tx'ed beacons to monitor mode

[Helmut Schaa]

When debugging wireless powersave issues on the AP side it's quite helpful
to see our own beacons that are transmitted by the hardware/driver. However,
this is not that easy since beacons don't pass through the regular TX queues.

Preferably drivers would call ieee80211_tx_status also for tx'ed beacons
but that's not always possible. Hence, just send a copy of each beacon
generated by ieee80211_beacon_get_tim to monitor devices when they are
getting fetched by the driver.
---
 net/mac80211/tx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 84e0e8c..f522579 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3512,6 +3512,9 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
 {
struct ieee80211_mutable_offsets offs = {};
struct sk_buff *bcn = __ieee80211_beacon_get(hw, vif, , false);
+   struct sk_buff *copy;
+   struct ieee80211_supported_band *sband;
+   int shift;
 
if (tim_offset)
*tim_offset = offs.tim_offset;
@@ -3519,6 +3522,13 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
if (tim_length)
*tim_length = offs.tim_length;
 
+   /* send a copy to monitor interfaces */
+   if (hw_to_local(hw)->monitors && (copy = skb_copy(bcn, GFP_ATOMIC))) {
+   shift = ieee80211_vif_get_shift(vif);
+   sband = 
hw->wiphy->bands[ieee80211_get_sdata_band(vif_to_sdata(vif))];
+   ieee80211_tx_monitor(hw_to_local(hw), copy, sband, 1, shift, 
true);
+   }
+
return bcn;
 }
 EXPORT_SYMBOL(ieee80211_beacon_get_tim);
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/2] Send own beacons to monitor interfaces

[Helmut Schaa]

Sending as RFC to gather some feedback. It can be quite useful
to see own beacons on monitor interfaces for debugging purposes.

However, since there is no tx status for beacons on most drivers
this patchset sends a copy of each beacon fetched via
ieee80211_beacon_get_tim to the monitor interfaces.

Of course, the beacon won't have proper seq numbers for example
as these are filled in in hw/fw.

Still this can be very helpful for debugging.

Helmut Schaa (2):
  mac80211: Split sending tx'ed frames to monitor interfaces into its
own function
  mac80211: Copy tx'ed beacons to monitor mode

 net/mac80211/ieee80211_i.h |   3 ++
 net/mac80211/status.c  | 108 +
 net/mac80211/tx.c  |  10 +
 3 files changed, 72 insertions(+), 49 deletions(-)

-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/2] mac80211: Copy tx'ed beacons to monitor mode

[Helmut Schaa]

On Tue, Sep 1, 2015 at 4:04 PM, Felix Fietkau <n...@openwrt.org> wrote:
> On 2015-09-01 12:12, Helmut Schaa wrote:
>> When debugging wireless powersave issues on the AP side it's quite helpful
>> to see our own beacons that are transmitted by the hardware/driver. However,
>> this is not that easy since beacons don't pass through the regular TX queues.
>>
>> Preferably drivers would call ieee80211_tx_status also for tx'ed beacons
>> but that's not always possible. Hence, just send a copy of each beacon
>> generated by ieee80211_beacon_get_tim to monitor devices when they are
>> getting fetched by the driver.
> How about also adding a hw flag to allow drivers to indicate that they
> submit tx status for beacons.

Makes sense, yes. Waiting for other comments before resending ...
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iw: print human readable radar events

[Helmut Schaa]

On Fri, Jan 30, 2015 at 11:36 AM, Joe Perches j...@perches.com 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
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] iw: print human readable radar events

[Helmut Schaa]

Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com
---
 event.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/event.c b/event.c
index c175c66..71ab7f7 100644
--- a/event.c
+++ b/event.c
@@ -565,6 +565,31 @@ static int print_event(struct nl_msg *msg, void *arg)
   nla_data(tb[NL80211_ATTR_VENDOR_DATA]),
   nla_len(tb[NL80211_ATTR_VENDOR_DATA]));
break;
+   case NL80211_CMD_RADAR_DETECT:
+   printf(radar event );
+   if (tb[NL80211_ATTR_RADAR_EVENT]) {
+   switch (nla_get_u32(tb[NL80211_ATTR_RADAR_EVENT])) {
+   case NL80211_RADAR_DETECTED:
+   printf((radar detected));
+   break;
+   case NL80211_RADAR_CAC_FINISHED:
+   printf((cac finished));
+   break;
+   case NL80211_RADAR_CAC_ABORTED:
+   printf((cac aborted));
+   break;
+   case NL80211_RADAR_NOP_FINISHED:
+   printf((nop finished));
+   break;
+   default:
+   printf((unknown));
+   break;
+   };
+   } else {
+   printf((unknown));
+   }
+   printf(\n);
+   break;
default:
printf(unknown event %d (%s)\n,
   gnlh-cmd, command_name(gnlh-cmd));
-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

DFS issue on ath10k

[Helmut Schaa]

Hi,

I've been seeing some issues with DFS on ath10k but this could
also affect ath9k.

In the end of the CAC period there seems to be a time window in
which ath10k won't detect any radar pulses (1sec) before starting
operation on this channel. Reason is that the channel context for
CAC is getting removed and it takes some time for hostapd to
finish the hw setup so a new channel context gets set.

This is no suitable patch but provides some more insight into
this issue:

--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -494,9 +494,9 @@

  if (!local-use_chanctx) {
  struct cfg80211_chan_def *chandef = local-_oper_chandef;
- chandef-width = NL80211_CHAN_WIDTH_20_NOHT;
+ /*chandef-width = NL80211_CHAN_WIDTH_20_NOHT;
  chandef-center_freq1 = chandef-chan-center_freq;
- chandef-center_freq2 = 0;
+ chandef-center_freq2 = 0;*/

  /* NOTE: Disabling radar is only valid here for
  * single channel context. To be sure, check it ...
@@ -504,7 +504,7 @@
  WARN_ON(local-hw.conf.radar_enabled 
  !list_empty(local-chanctx_list));

- local-hw.conf.radar_enabled = false;
+ local-hw.conf.radar_enabled =
cfg80211_chandef_dfs_required(local-hw.wiphy, chandef,
NL80211_IFTYPE_AP);

  ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
  } else {


Not sure how to get this race free. hostapd might have to configure
the channel before the CAC period is finished so there is no
window without channel context.

Did anyone else notice this? Any ideas?

Thanks,
Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DFS CAC time

[Helmut Schaa]

On Fri, Dec 19, 2014 at 1:28 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
 On 19 December 2014 at 12:27, Zefir Kurtisi zefir.kurt...@neratec.com wrote:
 On 12/18/2014 05:21 PM, Helmut Schaa wrote:
 Hi,

 [...]

 So, every channel has a CAC time of 60 seconds.

 Checking version 1.7.2 of the ETSI regulation indicates that we might
 need some modifications to cfg80211:

 From [1] page 79:

 NOTE 1: For channels whose nominal bandwidth falls completely or
 partly within the
 band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
 10 minutes.
 NOTE 2: For channels whose nominal bandwidth falls completely or
 partly within the
 band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
 range 1 hour to 24 hours.

 So, for these channels we should select a longer initial CAC time.

 Is anyone aware of this issue?

 Thanks,
 Helmut


 [1] 
 http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
 --

 Hello Helmut,

 just forget about those aka 'weather channels' that require a pracitcally
 impossible to achieve radar detection probability rate (99.99% during CAC, 
 see
 table D.5).

 They should simply be disabled, either at mac layer, or at least in 
 ath/regd.c.


 You can use internal regdb and set this correctly in db.txt, eg

 +   (5490 - 5600 @ 80), (27), DFS, AUTO-BW
 +   (5600 - 5650 @ 40), (27), (60), DFS, AUTO-BW
 +   (5650 - 5710 @ 40), (27), DFS, AUTO-BW

 There are also patches for crda/wireless-regdb but not merged, so use
 internal regdb.

Nice, didn't know about that one.

Thanks for the suggestion,
Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DFS CAC time

[Helmut Schaa]

Hi Zefir,

On Fri, Dec 19, 2014 at 12:27 PM, Zefir Kurtisi
zefir.kurt...@neratec.com wrote:
 On 12/18/2014 05:21 PM, Helmut Schaa wrote:
 Hi,

 [...]

 So, every channel has a CAC time of 60 seconds.

 Checking version 1.7.2 of the ETSI regulation indicates that we might
 need some modifications to cfg80211:

 From [1] page 79:

 NOTE 1: For channels whose nominal bandwidth falls completely or
 partly within the
 band 5 600 MHz to 5 650 MHz, the Channel Availability Check Time shall be
 10 minutes.
 NOTE 2: For channels whose nominal bandwidth falls completely or
 partly within the
 band 5 600 MHz to 5 650 MHz, the Off-Channel CAC Time shall be within the
 range 1 hour to 24 hours.

 So, for these channels we should select a longer initial CAC time.

 Is anyone aware of this issue?

 Thanks,
 Helmut


 [1] 
 http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.07.02_20/en_301893v010702a.pdf
 --

 Hello Helmut,

 just forget about those aka 'weather channels' that require a pracitcally
 impossible to achieve radar detection probability rate (99.99% during CAC, see
 table D.5).

Hmm, ok :)

Would it make sense to mark these somehow in the wireless-regdb in a
special way?

Thanks,
Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rt2x00: rt2x00queue: avoid using more headroom then driver requested

[Helmut Schaa]

Mark Asselstine asse...@gmail.com schrieb:
On Wed, Oct 1, 2014 at 9:42 PM, Mark Asselstine asse...@gmail.com
wrote:

 Damn, you are right. I thought I had it licked.

 Unfortunately with the overloaded variable name it was easy to get
turned
 around. The comments in the code didn't prevent me knotting myself up
 either. If you look in in rt2x00.h, struct rt2x00_dev, the comment
above the
 extra_tx_headroom member says Extra TX headroom required for
alignment
 purposes. I would say this is incorrect. This variable is
initialized
 via rt2x00dev_extra_tx_headroom() with a combination of winfo_size
and
 desc_size and has nothing to do with alignment.

 At any rate, keeping in mind that rt2x00_dev.hw.extra_tx_headroom
 which is used to set the amount of available headroom includes room
 for alignment and padding as well as winfo and desc space, and that
 rt2x00_dev.extra_tx_headroom doesn't include padding or alignment,
you
 are correct in that we aren't over spending our headroom. Back to the
 drawing board.


 Mark

 On Wed, Oct 1, 2014 at 5:12 AM, Stanislaw Gruszka
sgrus...@redhat.com
 wrote:

 On Tue, Sep 30, 2014 at 11:45:57PM -0400, Mark Asselstine wrote:
  'struct ieee80211_hw' contains 'extra_tx_headroom' which it
defines as
  headroom to reserve in each transmit skb for use by the driver.
This
  value is properly setup during rt2x00lib_probe_hw() to account for
all
  the rt2x00lib's purposes, including DMA alignment and L2 pad if
  needed. As such under all circumstances the proper amount of
headroom
  is allocated to a skb such that under any usage we would not ever
use
  more headroom then is allotted.
 
  However rt2x00queue_write_tx_frame() uses up the headroom (via
calls
  to skb_push) allotted for L2 padding (with a potential call to
  rt2x00queue_insert_l2pad()) and uses up the headroom allotted to
DMA
  alignment (with a potential call to rt2x00queue_align_frame()) and
  then proceeds to use up 'extra_tx_headroom' (in a call to
  rt2x00queue_write_tx_data())
 
  So the driver has requested just 'extra_tx_headroom' worth of
headroom
  and we have used up 'extra_tx_headroom' + DMA + L2PAD worth. As
such
  it is possible to hit a 'skb_under_panic', where we have used up
all
  the available headroom.
 
  Since extra_tx_headroom was calculated as a function of
winfo_size,
  desc_size, RT2X00_L2PAD_SIZE and RT2X00_ALIGN_SIZE we can simply
  remove the part for alignment and padding and we will know how
much is
  left to use up (for txdesc) and only use that much. Keeping the
  driver's use of headroom to what it requested via
extra_tx_headroom.
 
  Signed-off-by: Mark Asselstine asse...@gmail.com
  ---
   drivers/net/wireless/rt2x00/rt2x00queue.c | 15 ---
   1 file changed, 12 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c
  b/drivers/net/wireless/rt2x00/rt2x00queue.c
  index 8e68f87..2a48bf5 100644
  --- a/drivers/net/wireless/rt2x00/rt2x00queue.c
  +++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
  @@ -522,6 +522,7 @@ static int rt2x00queue_write_tx_data(struct
  queue_entry *entry,
 struct txentry_desc *txdesc)
   {
struct rt2x00_dev *rt2x00dev = entry-queue-rt2x00dev;
  + unsigned int avail_extra_tx_headroom =
  rt2x00dev-extra_tx_headroom;
 
/*
 * This should not happen, we already checked the entry
  @@ -538,10 +539,18 @@ static int rt2x00queue_write_tx_data(struct
  queue_entry *entry,
}
 
/*
  -  * Add the requested extra tx headroom in front of the skb.
  +  * Add room for data at the front of the buffer for txdesc.
The
  space
  +  * needed for this was accounted for in extra_tx_headroom,
we just
  +  * need to remove the amount allocated for padding and
alignment
  +  * to get what is left for txdesc.
 */
  - skb_push(entry-skb, rt2x00dev-extra_tx_headroom);
  - memset(entry-skb-data, 0, rt2x00dev-extra_tx_headroom);
  + if (test_bit(REQUIRE_L2PAD, rt2x00dev-cap_flags))
  + avail_extra_tx_headroom -= RT2X00_L2PAD_SIZE;
  + else if (test_bit(REQUIRE_DMA, rt2x00dev-cap_flags))
  + avail_extra_tx_headroom -= RT2X00_ALIGN_SIZE;
  +
  + skb_push(entry-skb, avail_extra_tx_headroom);
  + memset(entry-skb-data, 0, avail_extra_tx_headroom);

 I don't think patch is correct.

 We have rt2x00-extra_tx_headroom and rt2x00-hw-extra_tx_headroom.
 Second value, which we provide as maximum needed headroom to
mac80211
 is rt2x00-extra_tx_headrom + RT2X00_L2PAD_SIZE + RT2X00_ALIGN_SIZE.

 We really need to reserve rt2x00dev-extra_tx_headroom on TX skb, as
 this is room for metadata needed by H/W and if needed we should
reserve
 RT2x00_L2PAD_SIZE and RTX00_ALIGN_SIZE. There should be room for
that,
 since we provide bigger rt2x00-hw-extra_tx_headroom to mac80211.

 The only possibility to skb_under_panic I can see, is that we
retransmit
 frame and try to align it many times, but alignment should 

Re: Not reaching optimum speeds with IEEE 802.11n

[Helmut Schaa]

On Fri, Sep 12, 2014 at 4:11 AM, Sourav
sourav.chakrabo...@netcommwireless.com wrote:
 On 11/09/14 00:14, Helmut Schaa wrote:

 On Wed, Sep 10, 2014 at 10:42 AM, Arend van Spriel ar...@broadcom.com
 wrote:

 On 09/10/14 03:26, Sourav wrote:

 We are using Ralink chip Rt3072L (using rt2800usb drivers rt2800usb.c),

 The Ralink USB hardware is quite bad in reporting TX status and as
 such minstrel_ht cannot do proper rate selection.
 If you watch the rc stats at

 /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-0/stations/xx:xx:xx:xx:xx:xx/rc_stats
 you might see a lot of rate selection hopping.

 Regards.
 Helmut

 please take a look at the attachments the first one shows the rc_stats
 and iperf stats side by side on the router(iperf is running in client mode
 in the router).the second attachment is from a laptop which is running
 iperf in server mode.

 I don't see a lot of rate hopping in the rc_stats file, (T,t and P) rates
 are pretty much stable yet there is a big difference between those rates
 and the throughput using iperf..

Indeed, rc_stats looks acceptable.

 when you say Ralink USB hardware is quite bad in reporting TX status, do
 you mean that the HW reports less tx rate to minstrel_ht and so its rate
 calculation is screwed up?

The HW sometimes does not report the status of transmitted frames correctly.
The TX status register is a FIFO of 16 (or similar) elements and if
the driver is
not reading it fast enough the FIFO will overflow :( at least that
was the point
when I was looking at the ralink hardware last time. Not sure if something
changed recently.

 Can you please let me know the section of code inside Rc_80211_minstrel_ht.c
 (or somewhere else) which deals with getting the tx rate from ralink HW?

There is no special code in minstrel(_ht) in regard to rt2x00.

Are you able able to get some statistics on the receiver side (your
windows machine)
regarding TX rates and AMPDU lengths?

Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Not reaching optimum speeds with IEEE 802.11n

[Helmut Schaa]

On Wed, Sep 10, 2014 at 5:18 PM, Andreas Hartmann
andihartm...@freenet.de wrote:
 Hello Helmut!

 Helmut Schaa wrote:
 On Wed, Sep 10, 2014 at 10:42 AM, Arend van Spriel ar...@broadcom.com 
 wrote:
 On 09/10/14 03:26, Sourav wrote:
 We are using Ralink chip Rt3072L (using rt2800usb drivers rt2800usb.c),

 The Ralink USB hardware is quite bad in reporting TX status and as
 such minstrel_ht cannot do proper rate selection.

 Rate control of the vendor driver seems to work just fine (or at least
 better as minstrel_ht).

Indeed, the ralink proprietary rate control does not depend on per
frame statistics.


 Iow: minstrel_ht doesn't meet the requirements of ralink chipsets :-).

Yep.

 But this is not the only problem of rt2800usb. As long as a driver has
 the ability to damage a device [1], there is something more basically
 broken!

Also agreed.

Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Not reaching optimum speeds with IEEE 802.11n

[Helmut Schaa]

On Wed, Sep 10, 2014 at 10:42 AM, Arend van Spriel ar...@broadcom.com wrote:
 On 09/10/14 03:26, Sourav wrote:
 We are using Ralink chip Rt3072L (using rt2800usb drivers rt2800usb.c),

The Ralink USB hardware is quite bad in reporting TX status and as
such minstrel_ht cannot do proper rate selection.
If you watch the rc stats at
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-0/stations/xx:xx:xx:xx:xx:xx/rc_stats
you might see a lot of rate selection hopping.

Regards.
Helmut
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html