Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

2016-06-17 Thread Felix Fietkau
On 2016-06-17 15:48, Felix Fietkau wrote: > On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote: >> Felix Fietkau writes: >> >>> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote: This patch leaves the code for ath9k's internal per-node per-tid queues in place and just

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

2016-06-17 Thread Felix Fietkau
On 2016-06-17 15:41, Tim Shepard wrote: >> > diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h >> > b/drivers/net/wireless/ath/ath9k/ath9k.h >> > index 93b3793..caeae10 100644 >> > --- a/drivers/net/wireless/ath/ath9k/ath9k.h >> > +++ b/drivers/net/wireless/ath/ath9k/ath9k.h >> > @@ -145,8

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

2016-06-17 Thread Dave Taht
>> struct ath_atx_tid { >> struct list_head list; >> + struct sk_buff_head i_q; > Do we really need a third queue here? Instead of adding yet another > layer of queueing here, I think we should even get rid of buf_q. Less queues, more filling! > > Channel context based queue handling

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

2016-06-17 Thread Felix Fietkau
On 2016-06-17 15:43, Toke Høiland-Jørgensen wrote: > Felix Fietkau writes: > >> On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote: >>> This patch leaves the code for ath9k's internal per-node per-tid >>> queues in place and just modifies the driver to also pull from >>> the new

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

2016-06-17 Thread Felix Fietkau
On 2016-06-17 11:09, Toke Høiland-Jørgensen wrote: > This patch leaves the code for ath9k's internal per-node per-tid > queues in place and just modifies the driver to also pull from > the new mac80211 intermediate software queues, and implements > the .wake_tx_queue method, which will cause

[ath9k-devel] [PATCH] ath9k: Fix programming of minCCA power threshold

2016-06-17 Thread Sven Eckelmann
The function ar9003_hw_apply_minccapwr_thresh takes as second parameter not a pointer to the channel but a boolean value describing whether the channel is 2.4GHz or not. This broke (according to the origin commit) the ETSI regulatory compliance on 5GHz channels. Fixes: 3533bf6b15a0 ("ath9k: Fix

[ath9k-devel] unknown phase offset added to CSI measurement at 2.4 GHz?

2016-06-17 Thread Jeon
It is not directly related with ath9k, but with Intel 5300 NIC. In https://github.com/dhalperi/linux-80211n-csitool-supplementary/issues/6, dhalperi says: > On 2.4 GHz bands, it appears that each antenna experiences an unknown phase shift by a multiple of π/2 (or 90 degrees). This is probably

Re: [ath9k-devel] linearity of ath9k CSI phase

2016-06-17 Thread Jeon
Dear Joe Ayers Thanks for your response again. I started studying and investigating on antennas theories. Regards, Jeon. 2016-06-14 14:19 GMT+09:00 Joe Ayers : > This increased spacing looks to impact the detection angle before aliasing > occurs with grating lobes. Google