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.
>
On Tue, Jan 5, 2016 at 2:27 AM, Jia-Ju Bai wrote:
> On 01/05/2016 12:50 AM, Helmut Schaa wrote:
>>
>> 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,
rable MMPDUs.
Signed-off-by: Helmut Schaa
---
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
On Tue, Jan 5, 2016 at 4:35 PM, Johannes Berg 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 s
On Tue, Jan 5, 2016 at 4:52 PM, Johannes Berg 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 her
e mac80211 applied filtered frame handling
for the un-acked probe response.
Signed-off-by: Helmut Schaa
---
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/ne
On Sat, Oct 17, 2015 at 10:04 PM, Paul McQuade wrote:
> Removed empty spaces before/after parenthesis
>
> Signed-off-by: Paul McQuade
Just noticed these did not get applied by Kalle yet.
Looks good to me.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00
On Sat, Oct 17, 2015 at 11:06 PM, Paul McQuade wrote:
> Code Style: pointer is declared wrong
>
> Signed-off-by: Paul McQuade
Thanks for fixing this code style issue.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt2x00.h | 4 ++--
> 1 file changed, 2 insertio
On Thu, Jan 21, 2016 at 5:56 PM, Helmut Schaa
wrote:
> On Sat, Oct 17, 2015 at 10:04 PM, Paul McQuade wrote:
>> Removed empty spaces before/after parenthesis
>>
>> Signed-off-by: Paul McQuade
>
> Just noticed these did not get applied by Kalle yet.
Kalle, can you fix
On Sat, Oct 17, 2015 at 11:06 PM, Paul McQuade wrote:
> Removed empty spaces before/after parenthesis
>
> Signed-off-by: Paul McQuade
Looks valid to me as well.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt2x00.h | 24
> 1 file chan
On Sat, Oct 17, 2015 at 11:11 PM, Paul McQuade wrote:
> Space needed before open parenthesis
>
> Signed-off-by: Paul McQuade
Looks valid to me.
Acked-by: Helmut Schaa
> ---
> drivers/net/wireless/rt2x00/rt2x00debug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions
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 t
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/ma
.
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
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 bea
On Tue, Sep 1, 2015 at 4:04 PM, Felix Fietkau 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 n
This allows ieee80211_tx_monitor to be used directly for sending 802.11 frames
to all monitor interfaces.
Signed-off-by: Helmut Schaa
---
net/mac80211/ieee80211_i.h | 3 ++
net/mac80211/status.c | 108 +
2 files changed, 62 insertions(+), 49
report TX status for beacons.
Signed-off-by: Helmut Schaa
---
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 |
report TX status for beacons.
Signed-off-by: Helmut Schaa
---
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/mac802
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
>--
Signed-off-by: Helmut Schaa
---
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
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
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
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
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k
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
---
drivers/net/wireless/ath/ath9k/Kconfig | 40 +-
1 file changed, 20 inserti
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
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/driver
HAN_QUARTER_RATE
marcros instead.
Signed-off-by: Helmut Schaa
Cc: Felix Fietkau
---
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
Hi,
On Fri, Sep 5, 2014 at 11:43 PM, Luis R. Rodriguez wrote:
> Yeah this seems to be a corner case of the fact that we deal with
> locking for the last request only through RCU and we only annotate
> that the request was processed but don't add checks for when its
> about to be processed. At lea
On Wed, Sep 10, 2014 at 10:42 AM, Arend van Spriel 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
On Wed, Sep 10, 2014 at 5:18 PM, Andreas Hartmann
wrote:
> Hello Helmut!
>
> Helmut Schaa wrote:
>> On Wed, Sep 10, 2014 at 10:42 AM, Arend van Spriel
>> wrote:
>>> On 09/10/14 03:26, Sourav wrote:
>>>> We are using Ralink chip Rt3072L (using rt2800usb
On Fri, Sep 12, 2014 at 4:11 AM, Sourav
wrote:
> On 11/09/14 00:14, Helmut Schaa wrote:
>>
>> On Wed, Sep 10, 2014 at 10:42 AM, Arend van Spriel
>> wrote:
>>>
>>> On 09/10/14 03:26, Sourav wrote:
>>>>
>>>> We are using Ralink chip
Mark Asselstine schrieb:
>On Wed, Oct 1, 2014 at 9:42 PM, Mark Asselstine
>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
>>
Hi,
Using ath10k I get the following when checking the CAC times for an
ETSI regulatory domain:
iw list | grep CAC -B 2
* 5260 MHz [52] (20.0 dBm) (radar detection)
DFS state: available (for 342 sec)
DFS CAC time: 6 ms
* 5280 MHz [56] (20.0 dBm) (radar detection)
DFS state: available (f
On Fri, Dec 19, 2014 at 1:28 PM, Janusz Dziedzic
wrote:
> On 19 December 2014 at 12:27, Zefir Kurtisi wrote:
>> On 12/18/2014 05:21 PM, Helmut Schaa wrote:
>>> Hi,
>>>
>>> [...]
>>>
>>> So, every channel has a CAC time of 60 seconds.
Hi Zefir,
On Fri, Dec 19, 2014 at 12:27 PM, Zefir Kurtisi
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 indicate
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
36 matches
Mail list logo
