[ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

Performing spectral scans on 5 GHz channels may result in PHY errors
sent by the hardware, even if DFS support is not enabled in the driver
(e.g. channel scanning or passive monitoring). In that case channels may
falsely get marked as 'unusable'. To fix that, only process radar PHY
errors when radar is explicitly enabled in the driver.

Cc: Stable  [v3.10+]
Reported-by: Mathias Kretschmer 
Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/dfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/dfs.c 
b/drivers/net/wireless/ath/ath9k/dfs.c
index 726271c..3d04905 100644
--- a/drivers/net/wireless/ath/ath9k/dfs.c
+++ b/drivers/net/wireless/ath/ath9k/dfs.c
@@ -152,6 +152,12 @@ void ath9k_dfs_process_phyerr(struct ath_softc *sc, void 
*data,
return;
}
 
+   if (!sc->hw->conf.radar_enabled) {
+   ath_dbg(common, DFS,
+   "Error: received radar phyerr while radar was 
disabled\n");
+   return;
+   }
+
datalen = rs->rs_datalen;
if (datalen == 0) {
DFS_STAT_INC(sc, datalen_discards);
-- 
2.1.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

On Friday 09 January 2015 19:57:37 Arend van Spriel wrote:
> On 01/09/15 17:54, Simon Wunderlich wrote:
> > Performing spectral scans on 5 GHz channels may result in PHY errors
> > sent by the hardware, even if DFS support is not enabled in the driver
> > (e.g. channel scanning or passive monitoring). In that case channels may
> > falsely get marked as 'unusable'. To fix that, only process radar PHY
> > errors when radar is explicitly enabled in the driver.
> 
> Hi Simon,
> 
> Not an ath9k expert, but I would think those channels would already be
> marked as unusable, because DFS is disabled in the driver. Or does this
> also affect 5G channels that do not require DFS.
> 
> Regards,
> Arend

Hey Arend,

maybe that was not really clear, but this is talking about the DFS state 
"unusable". By default, channels are marked in DFS state "usable", and after 
the clear channel assessment (which is done e.g. when starting AP mode) they 
are marked as "available". As soon as radar is detected they are marked as 
"unusable".

These DFS state changes should only happen while there is something operating 
with radar enabled, e.g. AP mode. It should not happen if we just have monitor 
mode or scan for channels. These channels should then stay in their previous 
DFS state (e.g. 'usable'). This was borked and this patch tries to fix it. :)

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

On Tuesday 13 January 2015 11:16:02 Zefir Kurtisi wrote:
> On 01/10/2015 05:26 PM, Simon Wunderlich wrote:
> > On Friday 09 January 2015 19:57:37 Arend van Spriel wrote:
> >> On 01/09/15 17:54, Simon Wunderlich wrote:
> >>> Performing spectral scans on 5 GHz channels may result in PHY errors
> >>> sent by the hardware, even if DFS support is not enabled in the driver
> >>> (e.g. channel scanning or passive monitoring). In that case channels may
> >>> falsely get marked as 'unusable'. To fix that, only process radar PHY
> >>> errors when radar is explicitly enabled in the driver.
> >> 
> >> Hi Simon,
> >> 
> >> Not an ath9k expert, but I would think those channels would already be
> >> marked as unusable, because DFS is disabled in the driver. Or does this
> >> also affect 5G channels that do not require DFS.
> >> 
> >> Regards,
> >> Arend
> > 
> > Hey Arend,
> > 
> > maybe that was not really clear, but this is talking about the DFS state
> > "unusable". By default, channels are marked in DFS state "usable", and
> > after the clear channel assessment (which is done e.g. when starting AP
> > mode) they are marked as "available". As soon as radar is detected they
> > are marked as "unusable".
> > 
> > These DFS state changes should only happen while there is something
> > operating with radar enabled, e.g. AP mode. It should not happen if we
> > just have monitor mode or scan for channels. These channels should then
> > stay in their previous DFS state (e.g. 'usable'). This was borked and
> > this patch tries to fix it. :)
> > 
> > Cheers,
> > 
> >  Simon
> 
> Hi,
> 
> the issue here is that DFS and spectral use the same PHY_ERROR reporting
> mechanism, and the dfs module is still in its initial state prior the
> spectral support was added. With that, feeding the dfs detector with
> PHY_ERROR frames generated by spectral scanner might cause false radar
> detections.

Yup, that's right - we noticed that too, and its written in various places 
that the FFT and DFS hardware logic is shared. :)
> 
> I did not dig how the hw->conf.radar_enabled flag is set in monitor mode,
> but if it is same as for master (i.e. set for DFS channels), then it would
> be a better approach to prevent calling ath9k_dfs_process_phyerr()
> altogether from ath9k_rx_skb_preprocess() if not set.

Hm, you mean like - if radar_enabled then dfs_process, otherwise fft_process? 
That would might be more elegant indeed ...

The monitor mode does not have the radar flag enabled, 
cfg80211_chandef_dfs_required() returns 0 in this case.

> 
> And while you're at that: slaves do not need to scan for radar, might be
> worth checking if it makes sense to selectively disable radar detection in
> STA mode. I am using attached private OpenWRT patch for that - which still
> would interfere with spectral scanning. Generally, the PHY_ERROR processing
> should be reworked but becomes quite complicated when you take into account
> special use-cases. Think of radar events being treated differently
> depending on whether a master or a monitor detected them (OC-CAC vs. ISM).

I didn't check if that is enforced correctly, but 
cfg80211_chandef_dfs_required() returns if radar is required for the various 
interface types - AP, Adhoc and Mesh have it enabled if its a DFS channel, 
client, monitor, etc don't have it enabled. That gets marked in the sdata-
>radar_required, and ieee80211_is_radar_required() checks all interfaces if 
there is any interface which needs radar. So that should have been taken care 
of.

Therefore I think that this is already handled in cfg80211/mac80211 and ath9k 
should not check the iftype at all, but only check the radar_enabled flag.

Off-channel CAC is certainly a different beast, but as far as I know we 
currently don't support that anyway. :)

Cheers,
Simon

signature.asc
Description: This is a digitally signed message part.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

Hey Kalle,

On Thursday 15 January 2015 16:30:51 Kalle Valo wrote:
> Simon Wunderlich  writes:
> >> I did not dig how the hw->conf.radar_enabled flag is set in monitor mode,
> >> but if it is same as for master (i.e. set for DFS channels), then it
> >> would
> >> be a better approach to prevent calling ath9k_dfs_process_phyerr()
> >> altogether from ath9k_rx_skb_preprocess() if not set.
> > 
> > Hm, you mean like - if radar_enabled then dfs_process, otherwise
> > fft_process? That would might be more elegant indeed ...
> > 
> > The monitor mode does not have the radar flag enabled,
> > cfg80211_chandef_dfs_required() returns 0 in this case.
> 
> So are you going to send v2 or what's the plan? I didn't quite get the
> conclusion from the discussion.

sorry for the silence - yes, please drop this version, I'll send v2.

Thanks
Simon

signature.asc
Description: This is a digitally signed message part.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Fwd: [Battlemesh] Announcing Battlemesh V8 Maribor, Slovenia

[Simon Wunderlich]

I'm sure there are some on this list who will be interested in joining! Please 
spread the word. :)

--  Forwarded Message  --

Subject: [Battlemesh] Announcing Battlemesh V8 Maribor, Slovenia
Date: Monday 23 March 2015, 17:13:18
From: Musti 
To: Battle of the Mesh Mailing List 

==
   Announcing the Wireless Battle Mesh v8
(3rd - 9th of August 2015, Maribor, Slovenia)
==

The next 'Wireless Battle of the Mesh' will take place from Mon 3rd
till Sun 9th of August at Dom Obrambe Pekre, Maribor, Slovenia. The
event aims to bring together people from across the globe to test the
performance of different routing protocols for ad-hoc networks, like
Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s. Of course, new protocols
(working on OpenWrt) are always welcome!

It is not required to be active within the mentioned protocols, so if
you are a mesh networking enthusiast, community networking activist, or
have an interest in mesh networks in general, you have to check this out!

Information about the event is gathered at:
http://battlemesh.org/BattleMeshV8


Location


The event takes place at the Dom Obrambe Pekre, Maribor, Slovenia.
It features one large dining hall with an attached smaller hall for
talks, a large lecture theater, several smaller classrooms and an
outdoor auditorium. Expect to find nice community WiFi internet
connection (open.wlan-si.net), video projectors, beverage and snack
supplies and some curious hackers.

Participant Registration and Fee


The event itself is free of charge and open for all, so to register
without hotel and food supply, simply add your name to the participant
table.

http://battlemesh.org/BattleMeshV8/Participants

If you wish low cost accommodation, a special group booking has been
arranged. Payment in advance is required to get the full benefit of
the discount. Therefore, like for the previous event, this year's
edition features an "early bird low cost" registration program with two
accomodation options:

Hotel Milena:
-

Hotel Milena is a family run hotel under mountain Pohorje for which
the accommodation is offered in a package. Rooms are for 2-4 people,
some rooms have a double bed only. In the case of a large number of
participants some accommodation will be in the neighbouring hotels
as well. Breakfast is included. There is a 15min walk to the
conference venue.

Early bird booking is available for 6 nights (August 3rd to 9th)
for 150 EUR if payment is received before 18th April. The price
goes up to EUR 175,00 for all later payments. These late arrangements
are subject to availability.

Camping:


Camping Kekec is a camping place in the vicinity of Hotel Milena,
all the usual camping amnesties available. No breakfast included.
There are shops nearby, walking to the conference venue takes 18 minutes.

Early bird booking is available for 6 nights (August 3rd to 9th)
for 45 EUR if payment is received before 18th April The price
goes up to EUR 55,00 for all later payments. These late arrangements
are subject to availability.

General:


For any additional information, requests and inquiries get in touch
with the local organization team: battlemeshv8 at wlan-si.net

Of course, this package is not compulsory. You can also find your own
bed and food supply yourself during the event if you wish to do so.

Payment information can be found be found here on the Battlemesh Wiki:

http://battlemesh.org/BattleMeshV8#Participant_Registration_and_Fee

Spread the Word
===

Feel free to spread the word by forwarding this mail to all lists /
people that might be interested in it. Blogging about the event is more
than welcome, and if you do so, please add a ping-back to the wiki page:

http://battlemesh.org/BattleMeshV8

Contact
===

* Web: http://battlemesh.org/BattleMeshV8
* Email: http://ml.ninux.org/mailman/listinfo/battlemesh
* IRC: irc.freenode.net #battlemesh


Kind regards,
Musti
___
Battlemesh mailing list
battlem...@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh
-

signature.asc
Description: This is a digitally signed message part.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] ath9k: Problems with diversity on AR9330

[Simon Wunderlich]

Hey,

we have trouble with an AR9330 (Hornet) based AP. This device has 2 antennas, 
and is supposed to support diversity (2 RX, 1 TX). However, diversity is not 
really enabled because the "alternative" antenna is not considered as "good", 
because not enough frames are received. It seems that at 99% of the time, 
alt_rssi (read from rs->rs_rssi_ctl1) is invalid (set to ATH9K_RSSI_BAD, -128), 
while main_rssi (read from rs->rs_rssi_ctl0) usually has sane values.

We test by sending from a 1m distance (Laptop), and both antennas are 
connected, so the alternative antenna should usually get some sane frames too.

We have also tried to swap the antenna configuration of main and alt (LNA1 and 
LNA2), but only the alt_rssi will be invalid, and we then receive via the 
alternative antenna. We therefore think that the antenna wiring is not the 
problem.

We have also checked EEPROM values, which seem to be correct as well. FYI, 
register set after reading the EEPROM are:
AR_PHY_MC_GAIN_CTRL = 13EF0200
AR_PHY_CCK_DETECT = 803E6788

Any ideas/pointers/suggestions?

Thanks!
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: Problems with diversity on AR9330

[Simon Wunderlich]

Hey Shafi,

we had this checked out before, the EEPROM/EEP_ANT_DIV_CTL1 value is set to 
00c9,
so bit 6 and 7 are on (as checked in this function).

Cheers,
Simon

On Sat, Jul 07, 2012 at 04:02:12PM +0530, Mohammed Shafi wrote:
> > further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it  seems 
> > to be
> >  ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
> >  ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
> > will check it out whats the one bit difference in CCK_DETECT
> 
> also could you provide the output of the attached patch, i would just
> check the diversity
> configuration
> 
> 
> -- 
> thanks,
> shafi




signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] AR9330 hornet board stops beaconing after a few days (0xdeadbeef)

[Simon Wunderlich]

Hey guys,

now, finally after approx. 9 days the problem hit us again, this time with 
debug enabled.

The symptoms are the same as described before. I'm pasting part of the syslog 
of routers
200 and 201 where the calibrating output changes - this is the only thing I 
could find
which was really different from before.

Unfortunately I can't take anything useful out of the logs - to me, it looks 
like the
'NF calibrated' output changes out of the blue. I can provide full log files to 
anyone
interested.

Debug level was:

# cat /sys/kernel/debug/ieee80211/phy0/ath9k/debug
0x000ffe2d

Any ideas? The routers are still on and reachable in this errorneous state, so 
I can
check for more things. :)

Thanks,
Simon

=== router 200 ===
root@OpenWrt:/sys/kernel/debug/ieee80211/phy0/ath9k# head regdump
0x00 0xdeadbeef
0x04 0xdeadbeef
0x08 0xdeadbeef
0x0c 0xdeadbeef
0x10 0xdeadbeef
0x14 0xdeadbeef
0x18 0xdeadbeef
0x1c 0xdeadbeef
0x20 0xdeadbeef
0x24 0xdeadbeef


Aug 31 15:48:56 192.168.10.200 kernel: [706236.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:49:01 192.168.10.200 kernel: [706236.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -104 
Aug 31 15:49:25 192.168.10.200 kernel: [706266.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:49:31 192.168.10.200 kernel: [706266.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -104 
Aug 31 15:49:55 192.168.10.200 kernel: [706296.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:50:01 192.168.10.200 kernel: [706296.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -104 
Aug 31 15:51:22 192.168.10.200 kernel: [706309.81] ath: phy0: Resetting Cal 
1 state for channel 2462 
Aug 31 15:51:27 192.168.10.200 kernel: [706309.91] ath: phy0: starting IQ 
Mismatch Calibration 
Aug 31 15:51:32 192.168.10.200 kernel: [706326.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:51:37 192.168.10.200 kernel: [706326.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -104 
Aug 31 15:51:42 192.168.10.200 kernel: [706327.81] ath: phy0: 0: Chn 0 
pmi=0x0389beb7;pmq=0x03853165;iqcm=0x0015ca84; 
Aug 31 15:51:47 192.168.10.200 kernel: [706327.81] ath: phy0: Starting IQ 
Cal and Correction for Chain 0 
Aug 31 15:51:52 192.168.10.200 kernel: [706327.81] ath: phy0: Original: Chn 
0 iq_corr_meas = 0x0015ca84 
Aug 31 15:51:57 192.168.10.200 kernel: [706327.81] ath: phy0: Chn 0 
pwr_meas_i = 0x0389beb7 
Aug 31 15:52:02 192.168.10.200 kernel: [706327.81] ath: phy0: Chn 0 
pwr_meas_q = 0x03853165 
Aug 31 15:52:07 192.168.10.200 kernel: [706327.81] ath: phy0: iqCorrNeg is 
0x 
Aug 31 15:52:12 192.168.10.200 kernel: [706327.81] ath: phy0: Chn 0 iCoff = 
0x0006 
Aug 31 15:52:17 192.168.10.200 kernel: [706327.81] ath: phy0: Chn 0 qCoff = 
0x 
Aug 31 15:52:22 192.168.10.200 kernel: [706327.81] ath: phy0: Chn 0 : iCoff 
= 0x7a  qCoff = 0x0 
Aug 31 15:52:28 192.168.10.200 kernel: [706327.81] ath: phy0: Register 
offset (0x98dc) before update = 0x20007e01 
Aug 31 15:52:33 192.168.10.200 kernel: [706327.81] ath: phy0: Register 
offset (0x98dc) QI COFF (bitfields 0x3f80) after update = 0x20007d00 
Aug 31 15:52:48 192.168.10.200 kernel: [706356.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:52:53 192.168.10.200 kernel: [706356.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -104 
Aug 31 15:53:08 192.168.10.200 kernel: [706386.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:53:13 192.168.10.200 kernel: [706386.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -105 
Aug 31 15:53:28 192.168.10.200 kernel: [706416.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -104 
Aug 31 15:53:33 192.168.10.200 kernel: [706416.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -105 
Aug 31 15:53:49 192.168.10.200 kernel: [706446.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:53:54 192.168.10.200 kernel: [706446.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -105 
Aug 31 15:54:09 192.168.10.200 kernel: [706476.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:54:14 192.168.10.200 kernel: [706476.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -105 
Aug 31 15:54:29 192.168.10.200 kernel: [706506.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:54:34 192.168.10.200 kernel: [706506.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -104 
Aug 31 15:54:50 192.168.10.200 kernel: [706536.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:54:55 192.168.10.200 kernel: [706536.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -105 
Aug 31 15:55:10 192.168.10.200 kernel: [706566.11] ath: phy0: NF calibrated 
[ctl] [chain 0] is -105 
Aug 31 15:55:15 192.168.10.200 kernel: [706566.11] ath: phy0: NF calibrated 
[ext] [chain 0] is -105 
Aug 31 15:55:30 192.168.10.200 kernel: [70

Re: [ath9k-devel] AR9330 hornet board stops beaconing after a few days (0xdeadbeef)

[Simon Wunderlich]

Shafi,

On Mon, Sep 03, 2012 at 07:23:26PM +0530, Mohammed Shafi wrote:
> seems we are getting beacon stuck, though its not sufficient for triggering
> chip reset (or) atleast start noise floor calibration. Is this is in a 
> congested
> environment ? we can dump cycle counters . I think we need to have a
> WAR of chip reset if the cycle counters (busy is too high) inspite the MAC 
> hang
> signature . let me try too to figure out that WAR is already available (or)
> we got to enable it.

I'm living at a small village, and one or two neighbors may have access points 
too,
but that's it - this should be far from beeing busy. We mostly use these APs for
surfing with smart phones, this is also far from congesting them. ;)

TBH I don't really understand what you are talking about regarding WAR, etc, can
you please explain? What can we do to analyse the problem better?

Thanks,
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] AR9330 hornet board stops beaconing after a few days (0xdeadbeef)

[Simon Wunderlich]

ath9k fellows,

as it seems no one could find the cause for this problem so far. I'd therefore
like to create a workaround by checking one/some registers for 0xdeadbeef and
reset the chip if this is found.

Can anyone recommend a register which should never go 0xdeadbeef in a normal 
case?

From what i've seen, AR_CFG (0x0014) might be a good choice. My regdumps say:

bad regdump:  0x14 0xdeadbeef
good regdump: 0x14 0x0008010a

Unfortunately I don't have documentation to find out if this register can ever
go deadbeef in a normal case. :)

What do you think? (of course, a proper solution is still appreciated ...)

Cheers,
Simon


On Wed, Sep 05, 2012 at 04:20:52PM +0200, Sven Eckelmann wrote:
> On Wednesday 05 September 2012 07:08:47 Adrian Chadd wrote:
> > I don't think it's a stuck beacon WAR issue here; 0xdeadbeef really
> > does read like the MAC has gone to sleep.
> > 
> > Where's the complete register dump hiding?
> 
> It was not sent to the public mailing lists due to the size. You will receive 
> the dump mentioned in the first mail in some minutes.
> 
> Kind regards,
>   Sven




signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCHv2] ath9k_hw: Handle AR_INTR_SYNC_HOST1_FATAL on AR9003

[Simon Wunderlich]

Hey Adrian,

On Tue, Oct 02, 2012 at 06:13:37AM -0700, Adrian Chadd wrote:
> .. well, the rule here is "You shouldn't get PERR/FATAL interrupts."
> 
> Haven't I posted a summary of what those errors are?
> 
> Ok. So they're signals from the PCIe core (named host1_fatal and
> host1_perr. Helpfully.) Those errors occured during a DMA transfer.
> 
> So the question is why you're seeing PERR interrupts when creating an
> adhoc interface. That hints to me that something odd is going on..

thanks for the explanation!

> 
> I've seen these issues creep up when the NIC is in some way behaving
> very, very badly (lots of timeouts and sync errors with little to no
> traffic at all), which resulted in all kinds of odd and weird,
> unstable behaviour. After replacing the NIC with another NIC (in my
> case, an AR9280 -> AR9280 NIC :-) the errors went away and things
> continued swimmingly.

Sounds like a good solution, but I'm afraid it won't work for us. We
are using AR9330 SoCs (Hornet), and as long as we don't have a very sharp knife
we won't be able to replace the NIC ... And cutting a few thousand of
them will also not be funny.

I'm starting to lose a little bit of confidence in these insects ... :/

> 
> I'd have to go digging through the PCIe core source to figure out
> exactly what host1_peer and host1_fatal mean. I can if you'd like,
> it'll just take some time as I'm not familiar at all with the PCIe
> host interface.

It would at least be interesting if we are supposed to handle the interrupt
somehow, instead of resetting the chip.

Thanks,
Simon
> 
> Thanks,
> 
> 
> 
> Adrian
> 
> On 2 October 2012 03:33, Sven Eckelmann  wrote:
> > Interrupts with the sync_cause AR_INTR_SYNC_HOST1_FATAL has to be handled
> > using a chip reset. Otherwise a interrupt storm with unhandled interrupts
> > will cause a hang or crash of the machine.
> >
> > Signed-off-by: Sven Eckelmann 
> > ---
> > I was informed that AR_INTR_SYNC_HOST1_PERR should not be handled this way
> > because it can create system freezes after an adhoc interface was created.
> >
> > I really need some Atheros developer who can check the documentation to
> > verify the interpretation of these flags. Otherwise this is just guessing
> > and may lead to even bigger problems.
> >
> >  drivers/net/wireless/ath/ath9k/ar9003_mac.c |5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c 
> > b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> > index d5b2e0e..6031bdf 100644
> > --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> > +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> > @@ -311,6 +311,11 @@ static bool ar9003_hw_get_isr(struct ath_hw *ah, enum 
> > ath9k_int *masked)
> > if (sync_cause) {
> > ath9k_debug_sync_cause(common, sync_cause);
> >
> > +   if (sync_cause & AR_INTR_SYNC_HOST1_FATAL) {
> > +   ath_dbg(common, ANY, "received PCI FATAL 
> > interrupt\n");
> > +   *masked |= ATH9K_INT_FATAL;
> > +   }
> > +
> > if (sync_cause & AR_INTR_SYNC_RADM_CPL_TIMEOUT) {
> > REG_WRITE(ah, AR_RC, AR_RC_HOSTIF);
> > REG_WRITE(ah, AR_RC, 0);
> > --
> > 1.7.10.4
> >
> > --
> > 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
> --
> 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
> 


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

From: Mathias Kretschmer 

According to 802.11-2007 17.3.8.6 (slot time), the slot time should
be increased by 3 us * coverage class. The code only increased the
ack timeout, which is fixed by this patch.

We have noticed in our long shot scenario that we see less collisions
with this patch.

Signed-off-by: Mathias Kretschmer 
[add standard reference and commit message]
Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/hw.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 71cd9f0..1a3d483 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1114,7 +1114,8 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
}
 
/* As defined by IEEE 802.11-2007 17.3.8.6 */
-   acktimeout = slottime + sifstime + 3 * ah->coverage_class + ack_offset;
+   slottime += 3 * ah->coverage_class;
+   acktimeout = slottime + sifstime + ack_offset;
ctstimeout = acktimeout;
 
/*
-- 
1.7.10

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC 2/3] mac80211: add spectral_scan function, hook it up in scanning

[Simon Wunderlich]

Add spectral_scan function to driver functions, and hook it up
in the scanning code.

Using the spectral scan from within the scan function has the charme
that it already does all the channel surfing for us.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 include/net/mac80211.h|6 ++
 net/mac80211/driver-ops.h |   10 ++
 net/mac80211/scan.c   |3 +++
 net/mac80211/trace.h  |5 +
 4 files changed, 24 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e1293c7..8104b7d 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2428,6 +2428,10 @@ enum ieee80211_rate_control_changed {
  * @restart_complete: Called after a call to ieee80211_restart_hw(), when the
  * reconfiguration has completed. This can help the driver implement the
  * reconfiguration step. This callback may sleep.
+ *
+ * @spectral_scan: Asks the driver to perform a spectral scan on the currently
+ *  selected channel. Results are stored in the drivers internal structures
+ *  currently.
  */
 struct ieee80211_ops {
void (*tx)(struct ieee80211_hw *hw,
@@ -2602,6 +2606,8 @@ struct ieee80211_ops {
 struct ieee80211_chanctx_conf *ctx);
 
void (*restart_complete)(struct ieee80211_hw *hw);
+
+   void(*spectral_scan)(struct ieee80211_hw *hw);
 };
 
 /**
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 68c27aa..df6d582 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1004,4 +1004,14 @@ static inline void drv_restart_complete(struct 
ieee80211_local *local)
trace_drv_return_void(local);
 }
 
+static inline void drv_spectral_scan(struct ieee80211_local *local)
+{
+   might_sleep();
+
+   trace_drv_spectral_scan(local);
+   if (local->ops->spectral_scan)
+   local->ops->spectral_scan(&local->hw);
+   trace_drv_return_void(local);
+}
+
 #endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 8e9bb168..cd8a17b 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -665,6 +665,9 @@ static void ieee80211_scan_state_set_channel(struct 
ieee80211_local *local,
return;
}
 
+   if (local->scan_req->spec_scan && local->ops->spectral_scan)
+   drv_spectral_scan(local);
+
/*
 * Probe delay is used to update the NAV, cf. 11.1.3.2.2
 * (which unfortunately doesn't say _why_ step a) is done,
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index e9579b7..7efd325 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -1421,6 +1421,11 @@ DEFINE_EVENT(local_only_evt, drv_restart_complete,
TP_ARGS(local)
 );
 
+DEFINE_EVENT(local_only_evt, drv_spectral_scan,
+   TP_PROTO(struct ieee80211_local *local),
+   TP_ARGS(local)
+);
+
 /*
  * Tracing for API calls that drivers call.
  */
-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC 0/3] Add spectral scan support for Atheros AR92xx/AR93xx

[Simon Wunderlich]

This patchset is a first request for comments for the upcoming spectral
scan feature. It adds a new attribute to nl80211 to ask for a spectral
scan while scanning, because we cycle through the channels anyway at
this time. If enabled by the driver, spectral scan results will be
collected. This feature has been enabled for AR92xx and AR93xx based
chipsets. As the FFT samples are very hardware dependent, they are only
provided via a debugfs file for further evaluation.

We've also written a visual evaluation program for these samples (see
screenshot [1] and sourcecode [2]).

Many details are not known due to the fact that I don't have access to
Atheros specifications and details. Many things are done by guessing
and might be wrong. I'm therefore requesting help from Qualcomm/Atheros
guys to confirm or correct my findings. Apart from that, after
discussion I think we could integrate this patchset to allow other
people to work on this as well, even if it is experimental now.

Questions from my end:
 1. There are many TODOs/Comments in the patches regarding details,
please answer if you can. :)
 2. The output format is very Atheros-dependent. If my finding that 
byte n-4 is some kind of offset/exponent, I'd integrate this in
the debugfs output as well
 3. The data length varies pretty much, there might be some false
positives/PHY errors which are not FFT data - what should be
the correct length?
 4. Is there any special handling for HT40? At least the proprietary
driver symbol names suggest so [3]

(Possible) further work:
 1. Integrate this patchset, confirm/correct findings
 2. If anyone would like: Atheros proprietary driver seems to
support some kind of classification [3] (is this microwave? cordless
phone? whatever?)
 3. If other devices also offer spectral scan support: define a
common interface to use it (not debugfs).


[1] http://packetmixer.de/sdl_spec_scan2.png
[2] https://github.com/simonwunderlich/FFT_eval
[3] http://www.wehavemorefun.de/fritzbox/Ath_spectral.ko#Symbole

Simon Wunderlich (3):
  nl80211: add spec scan flag
  mac80211: add spectral_scan function, hook it up in scanning
  ath9k: add spectral scan feature

 drivers/net/wireless/ath/ath9k/ar9002_phy.c |   37 +
 drivers/net/wireless/ath/ath9k/ar9003_phy.c |   37 +
 drivers/net/wireless/ath/ath9k/ath9k.h  |   12 
 drivers/net/wireless/ath/ath9k/debug.c  |   79 +++
 drivers/net/wireless/ath/ath9k/hw.h |4 ++
 drivers/net/wireless/ath/ath9k/init.c   |   13 +
 drivers/net/wireless/ath/ath9k/mac.h|7 ++-
 drivers/net/wireless/ath/ath9k/main.c   |   29 ++
 drivers/net/wireless/ath/ath9k/recv.c   |   34 
 include/net/cfg80211.h  |2 +
 include/net/mac80211.h  |6 ++
 include/uapi/linux/nl80211.h|5 ++
 net/mac80211/driver-ops.h   |   10 
 net/mac80211/scan.c |3 +
 net/mac80211/trace.h|5 ++
 net/wireless/nl80211.c  |3 +
 16 files changed, 284 insertions(+), 2 deletions(-)

-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC 1/3] nl80211: add spec scan flag

[Simon Wunderlich]

This flag indicates that a spectrum scan is requested, if supported.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 include/net/cfg80211.h   |2 ++
 include/uapi/linux/nl80211.h |5 +
 net/wireless/nl80211.c   |3 +++
 3 files changed, 10 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8a1aec5..ce19e59 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1009,6 +1009,7 @@ struct cfg80211_ssid {
  * @wdev: the wireless device to scan for
  * @aborted: (internal) scan request was notified as aborted
  * @no_cck: used to send probe requests at non CCK rate in 2GHz band
+ * @spec_scan: indicates that spectral scan is requested while scanning.
  */
 struct cfg80211_scan_request {
struct cfg80211_ssid *ssids;
@@ -1027,6 +1028,7 @@ struct cfg80211_scan_request {
unsigned long scan_start;
bool aborted;
bool no_cck;
+   bool spec_scan;
 
/* keep last */
struct ieee80211_channel *channels[0];
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1a9a819..7da847f 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1292,6 +1292,9 @@ enum nl80211_commands {
  *
  * @NL80211_ATTR_SCAN_FLAGS: scan request control flags (u32)
  *
+ * @NL80211_ATTR_TX_SPEC_SCAN: Indicates whether a spectrum scan should be
+ * performed while scanning. Used with %NL80211_CMD_TRIGGER_SCAN command.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -1555,6 +1558,8 @@ enum nl80211_attrs {
 
NL80211_ATTR_SCAN_FLAGS,
 
+   NL80211_ATTR_TX_SPEC_SCAN,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4c427fa..2524509 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -337,6 +337,7 @@ static const struct nla_policy 
nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_ROAM_SUPPORT] = { .type = NLA_FLAG },
[NL80211_ATTR_SCHED_SCAN_MATCH] = { .type = NLA_NESTED },
[NL80211_ATTR_TX_NO_CCK_RATE] = { .type = NLA_FLAG },
+   [NL80211_ATTR_TX_SPEC_SCAN] = { .type = NLA_FLAG },
[NL80211_ATTR_TDLS_ACTION] = { .type = NLA_U8 },
[NL80211_ATTR_TDLS_DIALOG_TOKEN] = { .type = NLA_U8 },
[NL80211_ATTR_TDLS_OPERATION] = { .type = NLA_U8 },
@@ -4396,6 +4397,8 @@ static int nl80211_trigger_scan(struct sk_buff *skb, 
struct genl_info *info)
 
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
+   request->spec_scan =
+   nla_get_flag(info->attrs[NL80211_ATTR_TX_SPEC_SCAN]);
 
request->wdev = wdev;
request->wiphy = &rdev->wiphy;
-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC] iw: add spectral scan attribute to scan function

[Simon Wunderlich]

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 scan.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/scan.c b/scan.c
index 05bad0b..3e28722 100644
--- a/scan.c
+++ b/scan.c
@@ -70,7 +70,7 @@ static int handle_scan(struct nl80211_state *state,
DONE,
} parse = NONE;
int freq;
-   bool passive = false, have_ssids = false, have_freqs = false;
+   bool passive = false, have_ssids = false, have_freqs = false, spec_scan 
= false;
size_t tmp;
unsigned char *ies;
int flags = 0;
@@ -115,6 +115,10 @@ static int handle_scan(struct nl80211_state *state,
parse = DONE;
passive = true;
break;
+   } else if (strcmp(argv[i], "spec-scan") == 0) {
+   parse = NONE;
+   spec_scan = true;
+   break;
}
case DONE:
return 1;
@@ -151,6 +155,8 @@ static int handle_scan(struct nl80211_state *state,
nla_put_nested(msg, NL80211_ATTR_SCAN_FREQUENCIES, freqs);
if (flags)
NLA_PUT_U32(msg, NL80211_ATTR_SCAN_FLAGS, flags);
+   if (spec_scan)
+NLA_PUT_FLAG(msg, NL80211_ATTR_TX_SPEC_SCAN);
 
err = 0;
  nla_put_failure:
@@ -1450,7 +1456,7 @@ static int handle_scan_combined(struct nl80211_state 
*state,
dump_argv[0] = argv[0];
return handle_cmd(state, id, dump_argc, dump_argv);
 }
-TOPLEVEL(scan, "[-u] [freq *] [ies ] 
[lowpri,flush,ap-force] [ssid *|passive]", 0, 0,
+TOPLEVEL(scan, "[-u] [freq *] [ies ] 
[lowpri,flush,ap-force,spec-scan] [ssid *|passive]", 0, 0,
 CIB_NETDEV, handle_scan_combined,
 "Scan on the given frequencies and probe for the given SSIDs\n"
 "(or wildcard if not given) unless passive scanning is requested.\n"
@@ -1460,7 +1466,7 @@ COMMAND(scan, dump, "[-u]",
NL80211_CMD_GET_SCAN, NLM_F_DUMP, CIB_NETDEV, handle_scan_dump,
"Dump the current scan results. If -u is specified, print unknown\n"
"data in scan results.");
-COMMAND(scan, trigger, "[freq *] [ies ] 
[lowpri,flush,ap-force] [ssid *|passive]",
+COMMAND(scan, trigger, "[freq *] [ies ] 
[lowpri,flush,ap-force,spec-scan] [ssid *|passive]",
NL80211_CMD_TRIGGER_SCAN, 0, CIB_NETDEV, handle_scan,
 "Trigger a scan on the given frequencies with probing for the given\n"
 "SSIDs (or wildcard if not given) unless passive scanning is 
requested.");
-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature

[Simon Wunderlich]

Adds the spectral scan feature for ath9k. AR92xx and AR93xx chips
are supported for now. The spectral scan is triggered within a
channel scan from mac80211, results can be gathered via debugfs.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/ar9002_phy.c |   37 +
 drivers/net/wireless/ath/ath9k/ar9003_phy.c |   37 +
 drivers/net/wireless/ath/ath9k/ath9k.h  |   12 
 drivers/net/wireless/ath/ath9k/debug.c  |   79 +++
 drivers/net/wireless/ath/ath9k/hw.h |4 ++
 drivers/net/wireless/ath/ath9k/init.c   |   13 +
 drivers/net/wireless/ath/ath9k/mac.h|7 ++-
 drivers/net/wireless/ath/ath9k/main.c   |   29 ++
 drivers/net/wireless/ath/ath9k/recv.c   |   34 
 9 files changed, 250 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 846dd79..9d8199d 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -555,6 +555,42 @@ static void ar9002_hw_antdiv_comb_conf_set(struct ath_hw 
*ah,
REG_WRITE(ah, AR_PHY_MULTICHAIN_GAIN_CTL, regval);
 }
 
+void ar9002_hw_spectral_scan(struct ath_hw *ah)
+{
+   struct ath_common *common = ath9k_hw_common(ah);
+
+   REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
+
+   /* NOTE: this will generate a few samples ... lacking documentation,
+* I'm not really sure what these parameters mean.
+*/
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_COUNT, 8);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
+
+   /* Activate spectral scan */
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ACTIVE);
+
+   /* Poll for spectral scan complete */
+   if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
+  AR_PHY_SPECTRAL_SCAN_ACTIVE,
+  0, AH_WAIT_TIMEOUT)) {
+   ath_err(common, "spectral scan wait failed\n");
+   return;
+   }
+
+   /* Disable spectral scan */
+   REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ENABLE);
+}
+
 void ar9002_hw_attach_phy_ops(struct ath_hw *ah)
 {
struct ath_hw_private_ops *priv_ops = ath9k_hw_private_ops(ah);
@@ -571,6 +607,7 @@ void ar9002_hw_attach_phy_ops(struct ath_hw *ah)
 
ops->antdiv_comb_conf_get = ar9002_hw_antdiv_comb_conf_get;
ops->antdiv_comb_conf_set = ar9002_hw_antdiv_comb_conf_set;
+   ops->spectral_scan = ar9002_hw_spectral_scan;
 
ar9002_hw_set_nf_limits(ah);
 }
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index ce19c09..c79d701 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1450,6 +1450,42 @@ set_rfmode:
return 0;
 }
 
+void ar9003_hw_spectral_scan(struct ath_hw *ah)
+{
+   struct ath_common *common = ath9k_hw_common(ah);
+
+   REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
+
+   /* NOTE: this will generate a few samples ... lacking documentation,
+* I'm not really sure what these parameters mean.
+*/
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_COUNT, 8);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
+
+   /* Activate spectral scan */
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ACTIVE);
+
+   /* Poll for spectral scan complete */
+   if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
+  AR_PHY_SPECTRAL_SCAN_ACTIVE,
+  0, AH_WAIT_TIMEOUT)) {
+   ath_err(common, "spectral scan wait failed\n");
+   return;
+   }
+
+   /* Disable spectral scan */
+   REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ENABLE);
+}
+
 void ar9003_hw_attach_phy_ops(struct ath_hw *ah)
 {
struct ath_hw_private_ops *priv_ops = ath9k_hw_private_ops(ah);
@@ -1483,6 +1519,7 @@ void ar9003_hw_attach

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

On Tue, Oct 30, 2012 at 02:24:21PM +0100, Felix Fietkau wrote:
> [...]
>
> When I ran the test, the throughput degradation was so big that the
> links became almost useless. It was a long time ago, so maybe this was
> caused by another bug that has been fixed since. I will run another test
> with this patch in a current version...

Felix, did you have the chance to run another test on your link with this
patch? Would be interesting to know if it makes any difference. :)

Thanks,
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC 1/3] nl80211: add spec scan flag

[Simon Wunderlich]

Hello Johannes,

On Wed, Nov 28, 2012 at 01:43:36PM +0100, Johannes Berg wrote:
> On Wed, 2012-11-28 at 13:35 +0100, Johannes Berg wrote:
> > On Tue, 2012-11-27 at 20:01 +0100, Simon Wunderlich wrote:
> > > This flag indicates that a spectrum scan is requested, if supported.
> > 
> > That "if supported" here is pretty problematic. There's no way to know.
> > Feature flag maybe?

Hmm, I could certainly add a WIPHY_FLAG for that.

> > 
> > Also, there are scan flags now. However, I don't see that this should
> > (ab)use the scan function. It doesn't seem likely that you want to do
> > this while you're sending probe requests, etc. OTOH, it seems likely
> > you'd want identical dwell times on all channels to have comparable
> > values, which isn't the case here.

The times are not a big problem - at least for now, the spectral scan
is only done for a very short time [tm] when the channel is changed.

The main reason why I wanted to use this function is that it can be used
while operation, that is sending power save, forbidding payload tx, etc.

> > 
> > I really think you need to decouple the API for this from scanning.
> 
> And then you can also define APIs to get the data out. While I realize
> that the data is implementation-dependent, you could have an enum that
> indicates the data format and describes it:
> 
> @NL80211_SPECTRAL_DATA_ATHEROS: u8 rssi,ext_rssi,noise,fft_data[] ...
> 
> enum nl80211_spectral_data {
>   NL80211_SPECTRAL_DATA_ATHEROS,
>   ...
> };
> 
> Then you can define a function to send the data to the userspace socket
> that asked for it (yes, if you have a separate command you can send it
> only to that app... wohoo! :P ) and don't even have to store it in the
> kernel...

Calling the spectral scan and RX the FFT data are different things, but
yes, having everything in one application would be much better than
"trigger at X, receive at Y". 
> 
> So bottom line is that I think there are two choices:
> 1) for a proof of concept, implement it in debugfs only, in ath9k only,
>with e.g. a debugfs file that sets a flag that then triggers the
>spectral scan when you do a scan (using sw_scan_start, config hooks)
>--> no need to modify nl80211 at all

So the idea is something like:
 * open debugfs-file (e.g. with cat)
 * start scan "normally", without any flags
 * read debugfs results, and close it

Mhm, this is definitely possible, although not too beautiful as well. :)

It seems there is no way to trigger a scan from within ath9k/debugfs, right?

sw_scan_start() is currently undefined in ath9k, but we could add that.
By "config hooks" you mean the general config driver call to set the channel
etc?

I could also cycle channels within ath9k, but the main problem I see is that
I can't turn off TX/go into power save mode from the driver, or would you see
anything feasible? 

> 2) implement some well-defined API in nl80211, but don't tie it to
>scanning or a debugfs implementation of getting the data out, with
>versioning of the FFT data packets etc. so it can be updated later
>without breaking everything

I guess if we implement this in iw, this would be done similarly to scan,
e.g. trigger the scan and wait on the socket for results? Or would we
use events instead?

This would roughly mean:
 * duplicate the mac80211 scan part for spectral scan to cycle channels/be quite
   while doing this
 * duplicate iw scan (at least some parts), the interface could look very 
similar:
   trigger scan, on receive scan results on another socket, wait for completion
   (although iw still has this "warning, it's racy" thing inside. :] )

This looks like a whole lot of work, and would duplicate some code which
we need for scan and spec_scan (at least it looks like it). On the plus side,
this would be easier to change in the future (e.g. adding parameters for spec
scan, etc).

> 
> This hybrid isn't a good approach at all.

I don't like hybrid approach as well, but hoped that it could be "good enough"
for a proof of concept. If someone ever implements pattern matching, the
interface will probably change again as well.

Maybe you could find this idea acceptable: Keep on using the scan command plus
some flag/and or attribute, but send "FFT result" as events or within the scan
socket instead of using debugfs. What do you think?

Thanks for your review and suggestions! I'd like to discuss the alternatives
to fully understand them and then choose one. :)

Cheers,
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC 1/3] nl80211: add spec scan flag

[Simon Wunderlich]

Hey Jouni,

On Wed, Nov 28, 2012 at 03:29:36PM +, Malinen, Jouni wrote:
> 
> 
> On 11/28/12 7:19 AM, "Simon Wunderlich"
>  wrote:
> 
> >The main reason why I wanted to use this function is that it can be used
> >while operation, that is sending power save, forbidding payload tx, etc.
> 
> Have you looked at the remain-on-channel commands?
> 

TBH, today was the first time I've had a more close look. :)

> >It seems there is no way to trigger a scan from within ath9k/debugfs,
> >right?
> 
> I don't think there is nor that there should be.. Do you really need scan
> operating for this? I would use remain-on-channel commands from a user
> space app to go through the channels you want to analyze.
> 

Hmm, that would be possible as well ... Using the scan function is very
convenient as I don't have to think about cycling, channel lists, etc.
But putting more control to userspace is also possible, if we can ask the
driver to just have a "quick spectral peek" on another channel.

Anyway, you'd suggest to use the NL80211 remain on channel command for that?
Or add a new "spectral scan" nl80211 command to do a spectral scan on this
(or multiple) channels, and use the various functions from 
mac80211/offchannel.c?

BTW, is there any limitation to remain on channel commands, like will they
work on AP ifaces, Ad-Hoc ifaces, MultiSSID in general, etc?

> >I could also cycle channels within ath9k, but the main problem I see is
> >that
> >I can't turn off TX/go into power save mode from the driver, or would you
> >see
> >anything feasible?
> 
> Remain-on-channel should take care of that, but yes, that would not be
> triggered from ath9k, but from user space.

That sounds good. :)

Thanks for the hint!
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC 1/3] nl80211: add spec scan flag

[Simon Wunderlich]

On Wed, Nov 28, 2012 at 05:26:14PM +0100, Johannes Berg wrote:
> 
> > > > That "if supported" here is pretty problematic. There's no way to know.
> > > > Feature flag maybe?
> > 
> > Hmm, I could certainly add a WIPHY_FLAG for that.
> 
> nl80211 feature flag would be better
> 

OK, that would work too. Just that there are some Atheros Chips which don't
support spectral scan, like AR9160, but are supported by ath9k. I guess I'd
just set the feature if the chip revision is supported, from within ath9k.

> > > > Also, there are scan flags now. However, I don't see that this should
> > > > (ab)use the scan function. It doesn't seem likely that you want to do
> > > > this while you're sending probe requests, etc. OTOH, it seems likely
> > > > you'd want identical dwell times on all channels to have comparable
> > > > values, which isn't the case here.
> > 
> > The times are not a big problem - at least for now, the spectral scan
> > is only done for a very short time [tm] when the channel is changed.
> > 
> > The main reason why I wanted to use this function is that it can be used
> > while operation, that is sending power save, forbidding payload tx, etc.
> 
> That's not an argument for using the scan API. That might be an argument
> for piggy-backing on the scan *implementation*, but that's an orthogonal
> issue. Note how I didn't comment on patch 2 -- I do think piggy-backing
> on the scan implementation would be acceptable.

OK

> 
> > > So bottom line is that I think there are two choices:
> > > 1) for a proof of concept, implement it in debugfs only, in ath9k only,
> > >with e.g. a debugfs file that sets a flag that then triggers the
> > >spectral scan when you do a scan (using sw_scan_start, config hooks)
> > >--> no need to modify nl80211 at all
> > 
> > So the idea is something like:
> >  * open debugfs-file (e.g. with cat)
> >  * start scan "normally", without any flags
> >  * read debugfs results, and close it
> > 
> > Mhm, this is definitely possible, although not too beautiful as well. :)
> > 
> > It seems there is no way to trigger a scan from within ath9k/debugfs, right?
> 
> No.
> 
> > sw_scan_start() is currently undefined in ath9k, but we could add that.
> > By "config hooks" you mean the general config driver call to set the channel
> > etc?
> 
> I meant to trigger the data collection there.
> 
> > I could also cycle channels within ath9k, but the main problem I see is that
> > I can't turn off TX/go into power save mode from the driver, or would you 
> > see
> > anything feasible? 
> 
> Triggering it all from the driver doesn't seem possible, no. You could
> have the function take effect on the next scan, but it's still kinda
> hybrid. However, it wouldn't "pollute" nl80211 that way.
> 

OK, so it could look like:

echo start > debugfs/ath9k/spectral_scan
iw dev wlan0 scan
cat debugfs/ath9k/spectral_scan
[... get output ...]
echo stop > debugfs/ath9k/spectral_scan

yeah, that's still hybrid, but still simple.

> > > 2) implement some well-defined API in nl80211, but don't tie it to
> > >scanning or a debugfs implementation of getting the data out, with
> > >versioning of the FFT data packets etc. so it can be updated later
> > >without breaking everything
> > 
> > I guess if we implement this in iw, this would be done similarly to scan,
> > e.g. trigger the scan and wait on the socket for results? Or would we
> > use events instead?
> > 
> > This would roughly mean:
> >  * duplicate the mac80211 scan part for spectral scan to cycle channels/be 
> > quite
> >while doing this
> 
> No, I didn't say this. I said the API should be different, the
> implementation in mac80211 could very well just be "either going to send
> probes & wait, or collect spectral scan data and continue to the next
> channel"
> 
> >  * duplicate iw scan (at least some parts), the interface could look very 
> > similar:
> >trigger scan, on receive scan results on another socket, wait for 
> > completion
> >(although iw still has this "warning, it's racy" thing inside. :] )
> 
> Actually you need a separate application anyway, to interpret the
> results, so that application would
>  * open a socket
>  * send the spectral scan command
>  * read the results on the socket

Ah OK, so we would have a new nl80211 spectral scan command which then calls
the mac80211/scan stuff, but with special flags which the normal scan wouldn't
do. It could then return the results, and the current scan command wouldn't be
harmed. I hope I got this right? :)

Also, putting all this into iw to dump the raw data would be feasible, no?
Right now I'm dumping the data on some AP, but display it on another computer
(with a screen :] ), so this intermediate step is needed anyways.

Actually, the ath9k-only way seems to be faster for now. I'm not sure about
the data interpretation (offset/exponents etc), and I'd like to have
this confirmed/corrected before exporting results via nl80211 - I don't want
to change the data

Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature

[Simon Wunderlich]

Adrian,

thanks a lot for your feedback!

On Fri, Nov 30, 2012 at 08:00:51PM -0800, Adrian Chadd wrote:
> Not that I'm specifically getting into this in any deep way right now, but..
> 
> On 27 November 2012 11:01, Simon Wunderlich
>  wrote:
> 
> [snip] - this should apply to AR9380 and later I think.
> 

Actually I have pretty much the same code in both ar9002_phy.c and ar9003_phy.c,
because they get different register definitions (addresses etc) from their 
respective
header files.

You think that this wouldn't apply for AR9280? Is there something wrong or 
different
with the register access?

I have put scan count of 8 in here, but on AR9380 I get much more samples (more 
like
256). I haven't played with this very much, because "a couple" of samples was 
all I
needed for my graphical analyzer.

> > +void ar9002_hw_spectral_scan(struct ath_hw *ah)
> > +{
> > +   struct ath_common *common = ath9k_hw_common(ah);
> > +
> > +   REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
> > +
> > +   /* NOTE: this will generate a few samples ... lacking documentation,
> > +* I'm not really sure what these parameters mean.
> > +*/
> > +   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
> > +   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > +   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
> > +   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_COUNT, 8);
> > +   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
> > +   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
> > +
> > +   /* Activate spectral scan */
> > +   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > +   AR_PHY_SPECTRAL_SCAN_ACTIVE);
> > +
> > +   /* Poll for spectral scan complete */
> > +   if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
> > +  AR_PHY_SPECTRAL_SCAN_ACTIVE,
> > +  0, AH_WAIT_TIMEOUT)) {
> > +   ath_err(common, "spectral scan wait failed\n");
> > +   return;
> > +   }
> > +
> > +   /* Disable spectral scan */
> > +   REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > +   AR_PHY_SPECTRAL_SCAN_ENABLE);
> > +}
> > +
> 
> You shouldn't have to do this. There's two spectral scan modes (well, three) -
> 
> * when you're not decoding things, and you meet these parameters,
> please send me some events (I think the patent mentions this);
> * trigger _now_ and send me "X" events; then clear the spectral scan bit;
> * trigger _now_ and just send me infinite events - on earlier chips
> (AR9280 I think) the magic value may be 0; on the later values it may
> be 255. Someone should experiment.
> 
> I suggest you separate out "configure/enable/disable" and "trigger" as 
> options.

OK, yeah I can do that - guess we should have different function calls for this
then, too. Don't know if all of this should be callable from mac80211 as well.

> 
> Grr, mumble mumble open source developers mumble mumble.. :-)

What are you muttering about? :D

Should we rather keep this wonderful feature to the closed source world?
I don't think so :)

> 
> I suggest experimenting around with those particular parameters. You
> should be able to coax out specific numbers of spectral scan events
> when you set the COUNT parameter to something other than 8. But
> polling that bit isn't needed. It should be asynchronous.

As I said, on AR9220 it appears I get 8 samples when doing setting 
AR_PHY_SPECTRAL_SCAN_COUNT to 8 (plus maybe some other "stuff"/non-samples).
On AR9380 I'm not so sure. Probably need to play with it a little
more. Also, I don't know what "SHORT REPEAT" is supposed to mean, etc.

About polling, you mean the SCAN_ACTIVE bit? It is probably only
needed when I want to trigger for few samples and want to be informed when
it's finished -  which is a good thing when doing spectral scan (change channel,
start and wait for samples, change again). But we probably don't need to wait
for the "background spectral scanning" mode, that's right. If someone wants
to implement detection for interfering radio users, that mode would be useful.
I don't need it, but can prepare the neccesary functions.

So I'd repost then:
 * ath9k/debugfs only patch for now, as Johannes suggested - I think we
   should concentrate on this for now (their are still a lot of open
   questions in my init

[ath9k-devel] [RFCv2] Add spectral scan support for Atheros AR92xx/AR93xx

[Simon Wunderlich]

This patch(set) is the second iteration of the request for comments for
upcoming spectral scan feature. It adds spectral scan control and dump
features to debugfs. When the open questions regarding interpretation
are answered, I would like to build an interface to nl80211/mac80211.
Please see the open questions below, every hint is kindly appreciated. :)

This feature has been enabled for AR92xx and AR93xx based chipsets.
We've also written a visual evaluation program for these samples (see
screenshot [1] and sourcecode [2]).

Many details are not known due to the fact that I don't have access to
Atheros specifications and details. Many things are done by guessing
and might be wrong. I'm therefore requesting help from Qualcomm/Atheros
guys to confirm or correct my findings. Apart from that, after
discussion I think we could integrate this patchset to allow other
people to work on this as well, even if it is experimental now.

Questions from my end:
 1. There are many TODOs/Comments in the patches regarding details,
please answer if you can. :)
 2. The output format is very Atheros-dependent. If my finding that 
byte n-4 is some kind of offset/exponent, I'd integrate this in
the debugfs output as well
 3. The data length varies pretty much, there might be some false
positives/PHY errors which are not FFT data - what should be
the correct length?
 4. Is there any special handling for HT40? At least the proprietary
driver symbol names suggest so [3]

(Possible) further work:
 1. Integrate this patchset, confirm/correct findings
 2. If anyone would like: Atheros proprietary driver seems to
support some kind of classification [3] (is this microwave? cordless
phone? whatever?)
 3. If other devices also offer spectral scan support: define a
common interface to use it (not debugfs).

Changes to RFCv1:
 * remove nl80211/mac80211 stuff for now, to build a proper interface
   after intepretation/output stabilized
 * split spectral scan call into config, trigger and wait call, which can
   be called as desired (or depending on the mode)
 * use relay(fs) to stream spectral scan results (thanks for the hint Felix),
   this seems to be much cleaner - as long as we stay in debugfs

[1] http://packetmixer.de/sdl_spec_scan2.png
[2] https://github.com/simonwunderlich/FFT_eval
[3] http://www.wehavemorefun.de/fritzbox/Ath_spectral.ko#Symbole

Simon Wunderlich (1):
  ath9k: add spectral scan feature

 drivers/net/wireless/ath/ath9k/ar9002_phy.c |   52 ++
 drivers/net/wireless/ath/ath9k/ar9003_phy.c |   52 ++
 drivers/net/wireless/ath/ath9k/ath9k.h  |   36 +++
 drivers/net/wireless/ath/ath9k/debug.c  |  148 +++
 drivers/net/wireless/ath/ath9k/debug.h  |5 +
 drivers/net/wireless/ath/ath9k/hw.h |   26 +
 drivers/net/wireless/ath/ath9k/init.c   |6 ++
 drivers/net/wireless/ath/ath9k/mac.h|7 +-
 drivers/net/wireless/ath/ath9k/main.c   |   97 ++
 drivers/net/wireless/ath/ath9k/recv.c   |   28 +
 10 files changed, 455 insertions(+), 2 deletions(-)

-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFCv2] ath9k: add spectral scan feature

[Simon Wunderlich]

Adds the spectral scan feature for ath9k. AR92xx and AR93xx chips
are supported for now. The spectral scan is triggered by configuring
a mode through a debugfs control file. Samples can be gathered via
another relay debugfs file.

Essentially, to try it out:

echo chanscan > /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan_ctl
iw dev wlan0 scan
cat /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan0
echo disable > /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan_ctl

This feature is still experimental. After parameters have been
confirmed, the debugfs can be replaced by an nl80211/mac80211 interface.

The special "chanscan" mode is used to perform spectral scan while
mac80211 is scanning for channels. To allow this,
sw_scan_start/complete() ops have been added.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/ar9002_phy.c |   52 ++
 drivers/net/wireless/ath/ath9k/ar9003_phy.c |   52 ++
 drivers/net/wireless/ath/ath9k/ath9k.h  |   36 +++
 drivers/net/wireless/ath/ath9k/debug.c  |  148 +++
 drivers/net/wireless/ath/ath9k/debug.h  |5 +
 drivers/net/wireless/ath/ath9k/hw.h |   26 +
 drivers/net/wireless/ath/ath9k/init.c   |6 ++
 drivers/net/wireless/ath/ath9k/mac.h|7 +-
 drivers/net/wireless/ath/ath9k/main.c   |   97 ++
 drivers/net/wireless/ath/ath9k/recv.c   |   28 +
 10 files changed, 455 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 846dd79..50584df 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -555,6 +555,55 @@ static void ar9002_hw_antdiv_comb_conf_set(struct ath_hw 
*ah,
REG_WRITE(ah, AR_PHY_MULTICHAIN_GAIN_CTL, regval);
 }
 
+void ar9002_hw_spectral_scan_config(struct ath_hw *ah,
+   struct ath_spec_scan *param)
+{
+   if (!param->enabled) {
+   REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ENABLE);
+   return;
+   }
+   REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
+
+   if (param->short_repeat)
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
+   else
+   REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
+
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_COUNT, param->count);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_PERIOD, param->period);
+   REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
+ AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, param->fft_period);
+
+   return;
+}
+
+static void ar9002_hw_spectral_scan_trigger(struct ath_hw *ah)
+{
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
+   /* Activate spectral scan */
+   REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ACTIVE);
+}
+
+static void ar9002_hw_spectral_scan_wait(struct ath_hw *ah)
+{
+   struct ath_common *common = ath9k_hw_common(ah);
+
+   /* Poll for spectral scan complete */
+   if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
+  AR_PHY_SPECTRAL_SCAN_ACTIVE,
+  0, AH_WAIT_TIMEOUT)) {
+   ath_err(common, "spectral scan wait failed\n");
+   return;
+   }
+}
+
 void ar9002_hw_attach_phy_ops(struct ath_hw *ah)
 {
struct ath_hw_private_ops *priv_ops = ath9k_hw_private_ops(ah);
@@ -571,6 +620,9 @@ void ar9002_hw_attach_phy_ops(struct ath_hw *ah)
 
ops->antdiv_comb_conf_get = ar9002_hw_antdiv_comb_conf_get;
ops->antdiv_comb_conf_set = ar9002_hw_antdiv_comb_conf_set;
+   ops->spectral_scan_config = ar9002_hw_spectral_scan_config;
+   ops->spectral_scan_trigger = ar9002_hw_spectral_scan_trigger;
+   ops->spectral_scan_wait = ar9002_hw_spectral_scan_wait;
 
ar9002_hw_set_nf_limits(ah);
 }
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index ce19c09..e3d5a5b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1450,6 +1450,55 @@ set_rfmode:
return 0;
 }
 
+static void ar9003_hw_spectral_scan_config(struct ath_hw *ah,
+  struct ath_spec_scan *param)
+{
+   if (!param->enabled) {
+   REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+   AR_PHY_SPECTRAL_SCAN_ENABLE);
+   return;
+   }
+
+   REG_SET_BIT(ah, AR_P

[ath9k-devel] [PATCH 3/4] ath9k: reorder error codes for spectral

[Simon Wunderlich]

When using the spectral scan feature, frames with phy errors are
returned for further processing to the driver. However, if the frames
also have an invalid CRC (which seems to happen quite often), the frame
is marked with bad CRC and not with the PHY error bit. The FFT
processing function will thus miss the frames.

Fix this by changing the precedence in error marking.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/mac.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/mac.c 
b/drivers/net/wireless/ath/ath9k/mac.c
index b42be91..811007e 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -605,13 +605,13 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct 
ath_desc *ds,
 * reported, then decryption and MIC errors are irrelevant,
 * the frame is going to be dropped either way
 */
-   if (ads.ds_rxstatus8 & AR_CRCErr)
-   rs->rs_status |= ATH9K_RXERR_CRC;
-   else if (ads.ds_rxstatus8 & AR_PHYErr) {
+   if (ads.ds_rxstatus8 & AR_PHYErr) {
rs->rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
rs->rs_phyerr = phyerr;
-   } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
+   } else if (ads.ds_rxstatus8 & AR_CRCErr)
+   rs->rs_status |= ATH9K_RXERR_CRC;
+   else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH 4/4] ath9k: Update spectral scan output data

[Simon Wunderlich]

From: Sven Eckelmann 

The sample data received through the spectral scan can be either in big or
little endian byteorder. This information isn't stored in the output file.
Therefore it is not possible for the analyzer software to find the correct byte
order.

It is relative common to get the data from a low end AP in big endian mode and
transfer it to another computer in little endian mode to analyze it. Therefore,
it would be better to store it in network (big endian) byte order.

The extension of the 8 bit bins for each bin to 16 bit is not necessary. This
operation can be done in userspace or on a different machine. Instead the
max_exp defining the amount of shifting required for each bin is exported to
userspace.

The change of the output format requires a change of the type in the sample
tlv to allow the userspace program to correctly detect the bin format.

Reported-by: Zefir Kurtisi 
Signed-off-by: Sven Eckelmann 
[squashed patches, update commit message, rebase]
Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/ath9k.h |6 +++---
 drivers/net/wireless/ath/ath9k/recv.c  |   14 --
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 342edc5..67df864 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -864,7 +864,7 @@ static inline u8 spectral_bitmap_weight(u8 *bins)
  * interface.
  */
 enum ath_fft_sample_type {
-   ATH_FFT_SAMPLE_HT20 = 0,
+   ATH_FFT_SAMPLE_HT20 = 1,
 };
 
 struct fft_sample_tlv {
@@ -876,7 +876,7 @@ struct fft_sample_tlv {
 struct fft_sample_ht20 {
struct fft_sample_tlv tlv;
 
-   u8 __alignment;
+   u8 max_exp;
 
u16 freq;
s8 rssi;
@@ -888,7 +888,7 @@ struct fft_sample_ht20 {
 
u64 tsf;
 
-   u16 data[SPECTRAL_HT20_NUM_BINS];
+   u8 data[SPECTRAL_HT20_NUM_BINS];
 } __packed;
 
 void ath9k_tasklet(unsigned long data);
diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
b/drivers/net/wireless/ath/ath9k/recv.c
index 13ee37b..2af6f19 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1035,7 +1035,7 @@ static int ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
struct ath_radar_info *radar_info;
struct ath_ht20_mag_info *mag_info;
int len = rs->rs_datalen;
-   int i, dc_pos;
+   int dc_pos;
 
/* AR9280 and before report via ATH9K_PHYERR_RADAR, AR93xx and newer
 * via ATH9K_PHYERR_SPECTRAL. Haven't seen ATH9K_PHYERR_FALSE_RADAR_EXT
@@ -1064,8 +1064,9 @@ static int ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
 
fft_sample.tlv.type = ATH_FFT_SAMPLE_HT20;
fft_sample.tlv.length = sizeof(fft_sample) - sizeof(fft_sample.tlv);
+   fft_sample.tlv.length = __cpu_to_be16(fft_sample.tlv.length);
 
-   fft_sample.freq = ah->curchan->chan->center_freq;
+   fft_sample.freq = __cpu_to_be16(ah->curchan->chan->center_freq);
fft_sample.rssi = fix_rssi_inv_only(rs->rs_rssi_ctl0);
fft_sample.noise = ah->noise;
 
@@ -1105,14 +1106,15 @@ static int ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
/* mag data is at the end of the frame, in front of radar_info */
mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
 
-   /* Apply exponent and grab further auxiliary information. */
-   for (i = 0; i < SPECTRAL_HT20_NUM_BINS; i++)
-   fft_sample.data[i] = bins[i] << mag_info->max_exp;
+   /* copy raw bins without scaling them */
+   memcpy(fft_sample.data, bins, SPECTRAL_HT20_NUM_BINS);
+   fft_sample.max_exp = mag_info->max_exp & 0xf;
 
fft_sample.max_magnitude = spectral_max_magnitude(mag_info->all_bins);
+   fft_sample.max_magnitude = __cpu_to_be16(fft_sample.max_magnitude);
fft_sample.max_index = spectral_max_index(mag_info->all_bins);
fft_sample.bitmap_weight = spectral_bitmap_weight(mag_info->all_bins);
-   fft_sample.tsf = tsf;
+   fft_sample.tsf = __cpu_to_be64(tsf);
 
ath_debug_send_fft_sample(sc, &fft_sample.tlv);
return 1;
-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH 1/4] ath9k: add debug parameters for spectral scan

[Simon Wunderlich]

Export the various parameters to userspace.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/ath9k.h |1 +
 drivers/net/wireless/ath/ath9k/debug.c |  186 
 drivers/net/wireless/ath/ath9k/init.c  |7 ++
 drivers/net/wireless/ath/ath9k/main.c  |   23 ++--
 4 files changed, 200 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index b2d6c18..342edc5 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -754,6 +754,7 @@ struct ath_softc {
/* relay(fs) channel for spectral scan */
struct rchan *rfs_chan_spec_scan;
enum spectral_mode spectral_mode;
+   struct ath_spec_scan spec_config;
int scanning;
 
 #ifdef CONFIG_PM_SLEEP
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 6c5d313..012446d 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1035,6 +1035,182 @@ static const struct file_operations fops_spec_scan_ctl 
= {
.llseek = default_llseek,
 };
 
+static ssize_t read_file_spectral_short_repeat(struct file *file,
+  char __user *user_buf,
+  size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   char buf[32];
+   unsigned int len;
+
+   len = sprintf(buf, "%d\n", sc->spec_config.short_repeat);
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_spectral_short_repeat(struct file *file,
+   const char __user *user_buf,
+   size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   unsigned long val;
+   char buf[32];
+   ssize_t len;
+
+   len = min(count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, len))
+   return -EFAULT;
+
+   buf[len] = '\0';
+   if (kstrtoul(buf, 0, &val))
+   return -EINVAL;
+
+   if (val < 0 || val > 1)
+   return -EINVAL;
+
+   sc->spec_config.short_repeat = val;
+   return count;
+}
+
+static const struct file_operations fops_spectral_short_repeat = {
+   .read = read_file_spectral_short_repeat,
+   .write = write_file_spectral_short_repeat,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
+static ssize_t read_file_spectral_count(struct file *file,
+   char __user *user_buf,
+   size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   char buf[32];
+   unsigned int len;
+
+   len = sprintf(buf, "%d\n", sc->spec_config.count);
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_spectral_count(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   unsigned long val;
+   char buf[32];
+   ssize_t len;
+
+   len = min(count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, len))
+   return -EFAULT;
+
+   buf[len] = '\0';
+   if (kstrtoul(buf, 0, &val))
+   return -EINVAL;
+
+   if (val < 0 || val > 255)
+   return -EINVAL;
+
+   sc->spec_config.count = val;
+   return count;
+}
+
+static const struct file_operations fops_spectral_count = {
+   .read = read_file_spectral_count,
+   .write = write_file_spectral_count,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
+static ssize_t read_file_spectral_period(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   char buf[32];
+   unsigned int len;
+
+   len = sprintf(buf, "%d\n", sc->spec_config.period);
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_spectral_period(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   unsigned long val;
+   char buf[32];
+   ssize_t len;
+
+   len = min(count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, len))
+   return

[ath9k-devel] [PATCH 2/4] ath9k: drop spectral packets after processing them

[Simon Wunderlich]

Spectral packets are "bogus" packets and should not be further evaluated
by the RX path.

Statistics are added to keep track of these packets.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/debug.c |1 +
 drivers/net/wireless/ath/ath9k/debug.h |2 ++
 drivers/net/wireless/ath/ath9k/recv.c  |   37 +++-
 3 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 012446d..2bbdcf8 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -895,6 +895,7 @@ static ssize_t read_file_recv(struct file *file, char 
__user *user_buf,
RXS_ERR("RX-Bytes-All", rx_bytes_all);
RXS_ERR("RX-Beacons", rx_beacons);
RXS_ERR("RX-Frags", rx_frags);
+   RXS_ERR("RX-Spectral", rx_spectral);
 
if (len > size)
len = size;
diff --git a/drivers/net/wireless/ath/ath9k/debug.h 
b/drivers/net/wireless/ath/ath9k/debug.h
index a22c0d7..410d6d8 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -219,6 +219,7 @@ struct ath_tx_stats {
  * @rx_too_many_frags_err:  Frames dropped due to too-many-frags received.
  * @rx_beacons:  No. of beacons received.
  * @rx_frags:  No. of rx-fragements received.
+ * @rx_spectral: No of spectral packets received.
  */
 struct ath_rx_stats {
u32 rx_pkts_all;
@@ -237,6 +238,7 @@ struct ath_rx_stats {
u32 rx_too_many_frags_err;
u32 rx_beacons;
u32 rx_frags;
+   u32 rx_spectral;
 };
 
 struct ath_stats {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
b/drivers/net/wireless/ath/ath9k/recv.c
index d7c129b..13ee37b 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1023,9 +1023,9 @@ static s8 fix_rssi_inv_only(u8 rssi_val)
return (s8) rssi_val;
 }
 
-
-static void ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
-   struct ath_rx_status *rs, u64 tsf)
+/* returns 1 if this was a spectral frame, even if not handled. */
+static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
+  struct ath_rx_status *rs, u64 tsf)
 {
 #ifdef CONFIG_ATH_DEBUG
struct ath_hw *ah = sc->sc_ah;
@@ -1044,7 +1044,14 @@ static void ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
if (rs->rs_phyerr != ATH9K_PHYERR_RADAR &&
rs->rs_phyerr != ATH9K_PHYERR_FALSE_RADAR_EXT &&
rs->rs_phyerr != ATH9K_PHYERR_SPECTRAL)
-   return;
+   return 0;
+
+   /* check if spectral scan bit is set. This does not have to be checked
+* if received through a SPECTRAL phy error, but shouldn't hurt.
+*/
+   radar_info = ((struct ath_radar_info *)&vdata[len]) - 1;
+   if (!(radar_info->pulse_bw_info & SPECTRAL_SCAN_BITMASK))
+   return 0;
 
/* Variation in the data length is possible and will be fixed later.
 * Note that we only support HT20 for now.
@@ -1053,14 +1060,7 @@ static void ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
 */
if ((len > SPECTRAL_HT20_TOTAL_DATA_LEN + 2) ||
(len < SPECTRAL_HT20_TOTAL_DATA_LEN - 1))
-   return;
-
-   /* check if spectral scan bit is set. This does not have to be checked
-* if received through a SPECTRAL phy error, but shouldn't hurt.
-*/
-   radar_info = ((struct ath_radar_info *)&vdata[len]) - 1;
-   if (!(radar_info->pulse_bw_info & SPECTRAL_SCAN_BITMASK))
-   return;
+   return 1;
 
fft_sample.tlv.type = ATH_FFT_SAMPLE_HT20;
fft_sample.tlv.length = sizeof(fft_sample) - sizeof(fft_sample.tlv);
@@ -1093,7 +1093,7 @@ static void ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
memcpy(&bins[32], &vdata[33], SPECTRAL_HT20_NUM_BINS - 32);
break;
default:
-   return;
+   return 1;
}
 
/* DC value (value in the middle) is the blind spot of the spectral
@@ -1115,6 +1115,9 @@ static void ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
fft_sample.tsf = tsf;
 
ath_debug_send_fft_sample(sc, &fft_sample.tlv);
+   return 1;
+#else
+   return 0;
 #endif
 }
 
@@ -1202,8 +1205,12 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool 
hp)
unlikely(tsf_lower - rs.rs_tstamp > 0x1000))
rxs->mactime += 0x1ULL;
 
-   if ((rs.rs_status & ATH9K_RXERR_PHY))
-   ath_process_fft(sc, hdr, &am

[ath9k-devel] [PATCHv2 4/4] ath9k: Update spectral scan output data

[Simon Wunderlich]

From: Sven Eckelmann 

The sample data received through the spectral scan can be either in big or
little endian byteorder. This information isn't stored in the output file.
Therefore it is not possible for the analyzer software to find the correct byte
order.

It is relative common to get the data from a low end AP in big endian mode and
transfer it to another computer in little endian mode to analyze it. Therefore,
it would be better to store it in network (big endian) byte order.

The extension of the 8 bit bins for each bin to 16 bit is not necessary. This
operation can be done in userspace or on a different machine. Instead the
max_exp defining the amount of shifting required for each bin is exported to
userspace.

The change of the output format requires a change of the type in the sample
tlv to allow the userspace program to correctly detect the bin format.

Reported-by: Zefir Kurtisi 
Signed-off-by: Sven Eckelmann 
[s...@hrz.tu-chemnitz.de: squashed patches, update commit message, rebase, fix 
endianess bug]
Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
Changes to PATCH:
 * fixed endianess bug when sending the sample (Thanks Mathias)
---
 drivers/net/wireless/ath/ath9k/ath9k.h |6 +++---
 drivers/net/wireless/ath/ath9k/debug.c |6 --
 drivers/net/wireless/ath/ath9k/recv.c  |   14 --
 3 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 342edc5..67df864 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -864,7 +864,7 @@ static inline u8 spectral_bitmap_weight(u8 *bins)
  * interface.
  */
 enum ath_fft_sample_type {
-   ATH_FFT_SAMPLE_HT20 = 0,
+   ATH_FFT_SAMPLE_HT20 = 1,
 };
 
 struct fft_sample_tlv {
@@ -876,7 +876,7 @@ struct fft_sample_tlv {
 struct fft_sample_ht20 {
struct fft_sample_tlv tlv;
 
-   u8 __alignment;
+   u8 max_exp;
 
u16 freq;
s8 rssi;
@@ -888,7 +888,7 @@ struct fft_sample_ht20 {
 
u64 tsf;
 
-   u16 data[SPECTRAL_HT20_NUM_BINS];
+   u8 data[SPECTRAL_HT20_NUM_BINS];
 } __packed;
 
 void ath9k_tasklet(unsigned long data);
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 2bbdcf8..3714b97 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1236,11 +1236,13 @@ static int remove_buf_file_handler(struct dentry 
*dentry)
 void ath_debug_send_fft_sample(struct ath_softc *sc,
   struct fft_sample_tlv *fft_sample_tlv)
 {
+   int length;
if (!sc->rfs_chan_spec_scan)
return;
 
-   relay_write(sc->rfs_chan_spec_scan, fft_sample_tlv,
-   fft_sample_tlv->length + sizeof(*fft_sample_tlv));
+   length = __be16_to_cpu(fft_sample_tlv->length) +
+sizeof(*fft_sample_tlv);
+   relay_write(sc->rfs_chan_spec_scan, fft_sample_tlv, length);
 }
 
 static struct rchan_callbacks rfs_spec_scan_cb = {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c 
b/drivers/net/wireless/ath/ath9k/recv.c
index 13ee37b..2af6f19 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1035,7 +1035,7 @@ static int ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
struct ath_radar_info *radar_info;
struct ath_ht20_mag_info *mag_info;
int len = rs->rs_datalen;
-   int i, dc_pos;
+   int dc_pos;
 
/* AR9280 and before report via ATH9K_PHYERR_RADAR, AR93xx and newer
 * via ATH9K_PHYERR_SPECTRAL. Haven't seen ATH9K_PHYERR_FALSE_RADAR_EXT
@@ -1064,8 +1064,9 @@ static int ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
 
fft_sample.tlv.type = ATH_FFT_SAMPLE_HT20;
fft_sample.tlv.length = sizeof(fft_sample) - sizeof(fft_sample.tlv);
+   fft_sample.tlv.length = __cpu_to_be16(fft_sample.tlv.length);
 
-   fft_sample.freq = ah->curchan->chan->center_freq;
+   fft_sample.freq = __cpu_to_be16(ah->curchan->chan->center_freq);
fft_sample.rssi = fix_rssi_inv_only(rs->rs_rssi_ctl0);
fft_sample.noise = ah->noise;
 
@@ -1105,14 +1106,15 @@ static int ath_process_fft(struct ath_softc *sc, struct 
ieee80211_hdr *hdr,
/* mag data is at the end of the frame, in front of radar_info */
mag_info = ((struct ath_ht20_mag_info *)radar_info) - 1;
 
-   /* Apply exponent and grab further auxiliary information. */
-   for (i = 0; i < SPECTRAL_HT20_NUM_BINS; i++)
-   fft_sample.data[i] = bins[i] << mag_info->max_exp;
+   /* copy raw bins without scaling them */
+   memcpy(fft_sample.data, bins, SPECTRAL_HT20_NUM_BINS);
+   fft_sample.max_exp = mag_info->max_exp & 0xf;
 
fft_sample.max_magnitude = spectral_max_magnitud

Re: [ath9k-devel] [ath9k] spectral scan update: HT40

[Simon Wunderlich]

Hey Adrian,

thanks a lot for your update!

On Fri, Feb 01, 2013 at 11:02:00AM -0800, Adrian Chadd wrote:
> Hi all,
> 
> I've been tinkering with the HT40 spectral scan data (in FreeBSD,
> obviously :-) and I can finally state that I have it working and
> working reliably.
> 
> The notes:
> 
> * The "MAC does silly things to the spectral scan payload" problem
> there is in HT40 too, so you need similar correction code for that.
> I've not yet committed that to FreeBSD, but I will soon.
> * The HT40 lower and upper FFT bins in the radar / spectral scan are
> just that - lower and upper halves of a 40MHz wide FFT.
> * .. but the RSSI in the RX descriptor is Primary and Extension
> channel RSSI, so you need to match them up correctly with what's
> "lower" and "upper" - ie, in HT40- mode, the primary RSSI is the
> upper, and the extension RSSI is lower.
> * .. and yes, this means you calculate the bin power separately for
> the lower and upper bins.
> * On AR928x chips, the spectral scan FFT is done on chain 0. I don't
> think that's changed in AR93xx series chips. So, use RSSI and NF from
> chain 0, don't use the combined RSSI figures.

Ah, OK, that's probably relevant for the ath9k part as well.

> * RSSI can be below 0 dB, so make sure you factor that in.
> * IIRC, RSSI from the RX header is in half-dB increments, so make sure
> you factor that in.
> * Because of the MAC corruption bug, you can't disable "short report"
> - otherwise you don't know whether the spectral scan data results are
> corrupted or not. So yes, you have to enable short report and thus you
> get one result at a time in a PHY error.

Could we (in theory) enable short report stuff for newer chipsets, e.g.
93xx and newer? I thought there was a fix for that in "latest silicon",
although I don't know specifics

> 
> I've mostly working code in FreeBSD's subversion tree -
> http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in
> lib/libradarpkt and src/fft_eval .
> 
> I've begun fleshing out some documentation about spectral scan -
> https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan

Excellent! That's provides a good resource. :)
> 
> I'm going to work on the invalid packet length detection and
> correction, based on what our reference driver does and what Zefir has
> done. But once that's done, the basic data parsing and power
> calculation bits are done - I'll work on exporting it in a
> jquery-compatible fashion over a network socket so people (read: not
> me :-) can write some visualisation apps using HTML/javascript. That
> way both Linux and FreeBSD (and whoever else!) wifi hackers can
> leverage the same visualisation apps when hacking on this stuff.

Again, thanks a lot for your work! I'm currently busy with a few other
things and probably won't find time to work on the 40 MHz spectral in the
next weeks, so if anyone else wants to pick up here - the code has been
prepared for that. :)

In any case, please keep us posted, and keep up your good work!
Thanks,
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] improve operational ANI in Mesh mode

[Simon Wunderlich]

Hello Georgiewskiy,

On Sat, Feb 16, 2013 at 06:43:16AM +0400, Georgiewskiy Yuriy wrote:
> 
> Hi, in our setups we experience pure ANI operational in mesh mode
> VS AP mode, after debuffing and digging in ANI code i find what ANI
> in AP mode work in limited mode, i try this mode with mesh and seems
> getting same good operation as in AP mode, i am not familiar with ANI
> may be there is another better way to fix this issue?

We sometimes see some problems too where we suspect ANI, but we are not
and it's hard to reproduce. Our mesh networks are IBSS mode based, not
802.11s mesh, so I wonder if we can apply your findings to IBSS mode too.

Can you describe how your setup looks like, and what difference your patches
make? Did you experience some problem which was easily reproducable?
Also, do you plan to send a proper patch?

Thanks,
Simon

> 
> changes what i made:
> 
> diff -ruN compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c 
> compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c
> --- compat-drivers-3.7.6-1/drivers/net/wireless/ath/ath9k/ani.c   
> 2013-02-11 04:23:53.0 +0400
> +++ compat-drivers-3.7.6-1-new/drivers/net/wireless/ath/ath9k/ani.c   
> 2013-02-16 05:03:46.640746411 +0400
> @@ -303,7 +303,8 @@
>   ah->stats.ast_ani_reset++;
> 
>   /* only allow a subset of functions in AP mode */
> - if (ah->opmode == NL80211_IFTYPE_AP) {
> + if (ah->opmode == NL80211_IFTYPE_AP || ah->opmode == 
> NL80211_IFTYPE_MESH_POINT) {
> + ath_dbg(common, ANI, "only allow a subset of functions in AP or 
> MESH mode");
>   if (IS_CHAN_2GHZ(chan)) {
>   ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
>   ATH9K_ANI_FIRSTEP_LEVEL);
> @@ -323,7 +324,8 @@
> 
>   if (is_scanning ||
>   (ah->opmode != NL80211_IFTYPE_STATION &&
> -  ah->opmode != NL80211_IFTYPE_ADHOC)) {
> +  ah->opmode != NL80211_IFTYPE_ADHOC && + ah->opmode !=
> NL80211_IFTYPE_MESH_POINT)) {
>   /*
>* If we're scanning or in AP mode, the defaults (ini)
>* should be in place. For an AP we assume the historical
> 
> 
> 
> C уважением   With Best Regards
> Георгиевский Юрий.Georgiewskiy Yuriy
> +7 4872 711666+7 4872 711666
> факс +7 4872 711143   fax +7 4872 711143
> Компания ООО "Ай Ти Сервис"   IT Service Ltd
> http://nkoort.ru  http://nkoort.ru
> JID: ghh...@icf.org.ruJID: ghh...@icf.org.ru
> YG129-RIPEYG129-RIPE



signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] improve operational ANI in Mesh mode

[Simon Wunderlich]

Hey Adrian,

On Tue, Feb 19, 2013 at 08:31:25AM -0800, Adrian Chadd wrote:
> Well, ANI does adjust some of its parameters based on the beacon
> signal level. It uses that as an estimate for how "strong" the signal
> is likely to be and tunes the baseband to either be highly sensitive
> or slightly on the deafer side.
> 
> If you have many sources of beacons (read: ibss, mesh, TDMA in my
> case) then that particular feature of ANI can't be used and it should
> be disabled. The code should be special casing it.
> 
> I suggest someone writes a bunch of test functions:
> 
> * whether we see no beacons (ie, AP mode)
> * whether we see one set of beacons (ie, STA mode)
> * whether we see multiple sets of beacons (ie ,everything else)

this sounds useful - and easier to maintain than checking each
IFTYPE seperately (we add iftypes after all ...).

Maybe Felix knows more about this? He has ported ANI as far as I know. :)

Cheers,
Simon


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

Hey Felix,

just wanted to bump on this issue again, as it has not been applied
yet - the patch seems still valid, and Mathias results appear to show
that as well. What do you think?

Thanks,
Simon

On Fri, Dec 07, 2012 at 01:35:49PM +0100, Mathias Kretschmer wrote:
> Hi all,
> 
> On 10/30/2012 01:43 PM, Felix Fietkau wrote:
> >On 2012-10-30 1:07 PM, Simon Wunderlich wrote:
> >>From: Mathias Kretschmer 
> >>
> >>According to 802.11-2007 17.3.8.6 (slot time), the slot time should
> >>be increased by 3 us * coverage class. The code only increased the
> >>ack timeout, which is fixed by this patch.
> >>
> >>We have noticed in our long shot scenario that we see less collisions
> >>with this patch.
> >At some point I had the slot time increase in the driver, but noticed a
> >massive throughput degradation on 10-20 km links. Leaving the slot time
> >alone and changing only the ACK timeout fixed this. What distances did
> >you test?
> >
> >- Felix
> >
> 
> We've run some tests on a 5km .11a link to verify the proper
> functioning of this patch (slot time depending on coverage class)
> and the recent patch to ensure the shorter (9us) slot time is used
> in .11a adhoc mode.
> 
> According to the standard, the slot time should be calculated as follows:
> 
> slottime = 9us + 3 * ah->coverage_class;
> 
> For our link, this would be
> 
> slottime = 9 us + 3 * 10 = 39 us.   (coverage class 10: up to 4950 m)
> 
> If you look at the below TSFT histogram and try to determine the peaks
> (first column: diffTime, second column: frameCount), the slot time
> turns out to be roughly 39us, which fits pretty nicely with the
> expected result.
> 
> The TCP throughput (wget -O /dev/null) was very constant between 1.7
> and 1.8 MByte/s. Which, I'd say, is pretty decent for such a link
> (without TxOp, etc).
> 
> Similar measurements for a 10km link, reveal a slot time of about
> 71us, which also matches the theoretical figure pretty well:
> 
> slottime = 9us + 3 * 21 = 72
> 
> Therefore, both patches seem to ensure a proper MAC timing while
> yielding proper throughput.
> 
> Cheers,
> 
> Mathias
> 
> 
> 
> === TSFT Histogram (times in us) of 00:00:00:00:00:00, age 66s ===
> 411,945
> 412,5921
> 413,1534
> 450,1271
> 451,4286
> 452,1804
> 490,5592
> 491,731
> 528,773
> 529,3482
> 530,1177
> 567,693
> 568,3071
> 569,1022
> 599,552
> 607,3659
> 608,486
> 637,266
> 638,737
> 639,437
> 645,782
> 646,2103
> 647,929
> 677,1525
> 678,560
> 684,463
> 685,2337
> 686,589
> 715,276
> 716,1630
> 717,704
> 754,424
> 755,1518
> 756,889
> 794,2347
> 795,796
> 832,420
> 833,1800
> 834,891
> 975,315
> 1014,329
> 1015,257
> 
> 
> 
> 


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH-RESEND] ath9k: apply coverage class on slottime too

[Simon Wunderlich]

From: Mathias Kretschmer 

According to 802.11-2007 17.3.8.6 (slot time), the slot time should
be increased by 3 us * coverage class. The code only increased the
ack timeout, which is fixed by this patch.

We have noticed in our long shot scenario that we see less collisions
with this patch.

Signed-off-by: Mathias Kretschmer 
[add standard reference and commit message]
Signed-off-by: Simon Wunderlich 
---
resent after further testing and concensus (original patch from
Oct 2012, no changes made)
---
 drivers/net/wireless/ath/ath9k/hw.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 10eb6ba..7f25da8 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1100,7 +1100,8 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
}
 
/* As defined by IEEE 802.11-2007 17.3.8.6 */
-   acktimeout = slottime + sifstime + 3 * ah->coverage_class + ack_offset;
+   slottime += 3 * ah->coverage_class;
+   acktimeout = slottime + sifstime + ack_offset;
ctstimeout = acktimeout;
 
/*
-- 
1.7.10.4

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: Disable spectral scan code to fix crash on rmmod.

[Simon Wunderlich]

On Thu, May 09, 2013 at 11:07:14AM +0530, Sujith Manoharan wrote:
> gree...@candelatech.com wrote:
> > From: Ben Greear 
> > 
> > With CONFIG_ATH9K_DEBUGFS enabled, and slub memory poisoning
> > enabled, I see this crash on rmmod of ath9k.  I'm not sure how
> > to fix this properly, but in the meantime, this patch to disable
> > the spectral scan code works around the problem for me.
> > 
> > With memory poisoning and the verify_mem_not_deleted code
> > below added, the crash looks as follows...  The dentry
> > is not *always* freed at this point, probably because rcu
> > callbacks haven't completed.  You still get a crash soon
> > after, however.
> 
> The relay file should probably be closed before calling 
> ieee80211_unregister_hw().
> The ath9k debugfs directory is created inside the phy#/ directory and that 
> would
> get cleaned up when the wiphy is unregistered.
> 
> Does this help ?

Looks good to me, moving the closing of the relayfs file before the 
unregistering. Thanks
a lot for fixing my bugs, Sujith. :)

Acked-by: Simon Wunderlich 

(BTW, would you mind sending this as proper [PATCH] again?)


> 
> diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
> b/drivers/net/wireless/ath/ath9k/debug.c
> index 4101c4a..cecbe1f 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.c
> +++ b/drivers/net/wireless/ath/ath9k/debug.c
> @@ -1684,6 +1684,14 @@ void ath9k_get_et_stats(struct ieee80211_hw *hw,
>   WARN_ON(i != ATH9K_SSTATS_LEN);
>  }
>  
> +void ath9k_deinit_debug(struct ath_softc *sc)
> +{
> + if (config_enabled(CONFIG_ATH9K_DEBUGFS) && sc->rfs_chan_spec_scan) {
> + relay_close(sc->rfs_chan_spec_scan);
> + sc->rfs_chan_spec_scan = NULL;
> + }
> +}
> +
>  int ath9k_init_debug(struct ath_hw *ah)
>  {
>   struct ath_common *common = ath9k_hw_common(ah);
> diff --git a/drivers/net/wireless/ath/ath9k/debug.h 
> b/drivers/net/wireless/ath/ath9k/debug.h
> index 62da19c..223418d 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.h
> +++ b/drivers/net/wireless/ath/ath9k/debug.h
> @@ -297,6 +297,7 @@ struct ath9k_debug {
>  };
>  
>  int ath9k_init_debug(struct ath_hw *ah);
> +void ath9k_deinit_debug(struct ath_softc *sc);
>  
>  void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status);
>  void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
> @@ -332,6 +333,10 @@ static inline int ath9k_init_debug(struct ath_hw *ah)
>   return 0;
>  }
>  
> +static inline void ath9k_deinit_debug(struct ath_softc *sc)
> +{
> +}
> +
>  static inline void ath_debug_stat_interrupt(struct ath_softc *sc,
>   enum ath9k_int status)
>  {
> diff --git a/drivers/net/wireless/ath/ath9k/init.c 
> b/drivers/net/wireless/ath/ath9k/init.c
> index c7b888f..c0aa4ff 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -903,7 +903,7 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc,
>   if (!ath_is_world_regd(reg)) {
>   error = regulatory_hint(hw->wiphy, reg->alpha2);
>   if (error)
> - goto unregister;
> + goto debug_cleanup;
>   }
>  
>   ath_init_leds(sc);
> @@ -911,6 +911,8 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc,
>  
>   return 0;
>  
> +debug_cleanup:
> + ath9k_deinit_debug(sc);
>  unregister:
>   ieee80211_unregister_hw(hw);
>  rx_cleanup:
> @@ -939,11 +941,6 @@ static void ath9k_deinit_softc(struct ath_softc *sc)
>   sc->dfs_detector->exit(sc->dfs_detector);
>  
>   ath9k_eeprom_release(sc);
> -
> - if (config_enabled(CONFIG_ATH9K_DEBUGFS) && sc->rfs_chan_spec_scan) {
> - relay_close(sc->rfs_chan_spec_scan);
> - sc->rfs_chan_spec_scan = NULL;
> - }
>  }
>  
>  void ath9k_deinit_device(struct ath_softc *sc)
> @@ -957,6 +954,7 @@ void ath9k_deinit_device(struct ath_softc *sc)
>  
>   ath9k_ps_restore(sc);
>  
> + ath9k_deinit_debug(sc);
>   ieee80211_unregister_hw(hw);
>   ath_rx_cleanup(sc);
>   ath9k_deinit_softc(sc);
> --
> 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


signature.asc
Description: Digital signature
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels

[Simon Wunderlich]

Kamran,

> Hi,
> I want to set 5 and 10 MHz channels. My AP has *Atheros* AR9160 and my
> nodes have AR5416. Are they supported for my cards. Can I go to higher MCS
> like 12-13 on  a 5MHz channel?

I'm not completely sure about AR5416, but AR9160 should support 5/10 MHz 
channels. However mac80211 does not support HT-rates on 5/10 MHz channels, 
although the hardware supports it. The standard does not specify HT rates in 
narrow channels. 

If you want that, you might need to use hacks in ath9k while mac80211 thinks 
it is operating on 20 MHz (this would be non-standard behaviour, of course). I 
don't know about specific MCS rates though.

Cheers,
Simon
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels

[Simon Wunderlich]

>  11/11/2013 3:15 PM, ?/? Kamran Nishat ??:
> > Dear Alex,
> > Can you send me updates in driver to make it support 5/10Mhz channel
> > both at client and AP ath9k. Also how can i set my channel to 5/10Mhz
> > in settings.
> > Kamran
> > 
> > 
> > On Mon, Nov 11, 2013 at 2:16 PM, Alex Hacker  > 
> > > wrote:
> > Thank you Adrian. Yes I know, but I can not get it working with
> > AR9390 (enterprise) chip too. :(
> > Alex.
> > 
> > ___
> > ath9k-devel mailing list
> > ath9k-devel@lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 
> Dear all,
> 
> I am also trying to reduce channel width to 5/10 MHZ. So far I managed
> to see the code inside the ath9k driver. More particulary in hw.c and
> ar9003_phy.c the functions "IS_CHAN_QUARTER_RATE" and
> "IS_CHAN_HALF_RATE" exist. These functions take values from the hw.h
> file, #define IS_CHAN_HALF_RATE(c) (((_c)->channelFlags &
> CHANNEL_QUARTER)   !=0 . From what I understand, this function changes
> the clockrate value which in turn affects the PLL value. In a paper
> reported that these values are responsible for channel width.
> 
> The question is how can I enable these half/quarter rate functions. For
> example when you want to set the channel width to 40MHZ, you simply
> type: iw dev "XXX" set channel "X" HT40+ . Also is this possible for
> AR9380 chipset and if so, is this possible via driver configuration?  Is
> there anyone of you who achieved this?

Tomas,

I've worked on this feature, it is working in IBSS mode, for AP mode we are 
still lacking hostap support. Therefore I've never tried client mode as well.

I still had a patch for iw on my disk which enables 5/10 MHz for the "iw join 
ibss" command, which I forgot to send. I've cleaned it up and sent it to 
linux-wireless[1], so you can have a look.

Cheers,
Simon

[1] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115597
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels

[Simon Wunderlich]

Hey Tomas,
> > I still had a patch for iw on my disk which enables 5/10 MHz for the "iw
> > join ibss" command, which I forgot to send. I've cleaned it up and sent
> > it to linux-wireless[1], so you can have a look.
> > 
> > Cheers,
> > 
> >  Simon
> > 
> > [1] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115597
> > ___
> > ath9k-devel mailing list
> > ath9k-devel@lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 
> Dear Simon,
> 
> thanks a lot for your immediate response. I looked at the patch you gave
> us. Can you tell us in what driver is this pacth applicable?
> I have tried mine but a lot of source code was missing.
> 
> Thank you in advance
> 
> Tomas

the patch is for the iw tool, Johannes has already merged it, so just check 
out the latest trunk of iw[1]. It should work on recent kernels (3.12 or 
mac80211-next) with ath5k and ath9k, but there was a reporting problem[2] 
which forced us to disable the support for now. If you revert the disabling 
patch [3] manually and understand that this may lead to an incompatible kernel 
you may still use it though, or use later kernels (or mac80211-next).

Cheers,
   Simon

[1] git clone http://git.kernel.org/?p=linux/kernel/git/jberg/iw.git
[2] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115842
[3] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115841
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels

[Simon Wunderlich]

Hey Kamran,

for 2.4 GHz that's certainly possible, as those are 5 MHz spaced anyway.

For 5 GHz I don't know if it's possible. For example in ath9k, you could try 
to hack ath9k_5ghz_chantable, add more channels in 5 mhz spaces and try if it 
works. The driver says here:

/* Some 5 GHz radios are actually tunable on -
 * on 5 MHz steps, we support the channels which we know
 * we have calibration data for all cards though to make
 * this static */

I don't know if it works, please give it a try and report back. :)
   Simon

> Can I change the center of my 5/10MMHz channel so I can accommodated more
> than one channels in official 802.11 20Mhz channel? If not then is it for
> HW reason or b/c of driver?
> 
> On Mon, Nov 18, 2013 at 4:07 PM, Simon Wunderlich 
wrote:
> > Hey Tomas,
> > 
> > > > I still had a patch for iw on my disk which enables 5/10 MHz for the
> > 
> > "iw
> > 
> > > > join ibss" command, which I forgot to send. I've cleaned it up and
> > > > sent it to linux-wireless[1], so you can have a look.
> > > > 
> > > > Cheers,
> > > > 
> > > >  Simon
> > > > 
> > > > [1]
> > 
> > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115597
> > 
> > > > ___
> > > > ath9k-devel mailing list
> > > > ath9k-devel@lists.ath9k.org
> > > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> > > 
> > > Dear Simon,
> > > 
> > > thanks a lot for your immediate response. I looked at the patch you
> > > gave us. Can you tell us in what driver is this pacth applicable?
> > > I have tried mine but a lot of source code was missing.
> > > 
> > > Thank you in advance
> > > 
> > > Tomas
> > 
> > the patch is for the iw tool, Johannes has already merged it, so just
> > check out the latest trunk of iw[1]. It should work on recent kernels
> > (3.12 or mac80211-next) with ath5k and ath9k, but there was a reporting
> > problem[2] which forced us to disable the support for now. If you revert
> > the disabling patch [3] manually and understand that this may lead to an
> > incompatible kernel
> > you may still use it though, or use later kernels (or mac80211-next).
> > 
> > Cheers,
> > 
> >Simon
> > 
> > [1] git clone http://git.kernel.org/?p=linux/kernel/git/jberg/iw.git
> > [2] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115842
> > [3] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115841
---
Mit freundlichen Grüßen / kind regards
Simon Wunderlich

Fon: +49 (0) 3741 / 2518068-0
Fax: +49 (0) 3741 / 2518068-9
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels

[Simon Wunderlich]

Kamran,

> I have an AP with  AR9160 tunning openWRT. When I set chennel to 10MHz from
> debugfs entry. I can still connect it with other boards running OpenWrt.
> But from computers running latest linux kernel it was visible in scan when
> I was using AR5416 but I was not able to connect to my AP.
> Then I changed NIC to Atheros AR9227 based card not I can even see openwrt
> AP with 10MHz channel.

Please note that the OpenWRT and the mainline Linux implementation of 5/10 MHz 
are different. In Linux we have a limited but (hopefully) standard-conforming 
implementation, that means that also bitrates are interpreted for their 
respective frequencies. For example on mainline LInux in 5 MHz mode you have 
OFDM bitrates of 1.5, 2.25, 3, 4.5 Mbit/s etc what would be 6, 9, 12, 18 
Mbit/s on 20 MHz. OpenWRT will just announce the 20 MHz bitrates even on 5 MHz 
(it's more of a hack). This will likely confuse the Linux clients. There might 
also be other knobs not complete, as I said I've only tested the IBSS mode.

For the record I tested AR9220 and AR5213 in 5 and 10 MHz mode and after some 
timing corrections (patches have been merged upstream) this worked quite well.

I'd recommend to use only the same implementation together.

Cheers,
Simon

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

Hello ath9k-devs,

we have an issue with a new QCA9558 SoC based board (Rev 0, a 3x3 2.4G board). 
We were doing performance tests with various 2-stream 802.11n clients, but 
appearently the high MCS rates 14 and 15 can not be used reliably with ath9k - 
rc_stats show that transmission fail most of the time, and the connected 
clients don't receive them as well. The original firmware with an Atheros 9.5 
driver (9.5.3.15) does not show that behaviour and works fine. Therefore we 
assume that there is something missing/wrong in ath9k. Iperf tests in HT20 
showed 60 Mbit/s with ath9k and 80 Mbit/s with the original firmware (distance 
1-3 meter).

We have been in contact with Sujith who kindly helped us and checked for 
updates, thanks to his work some patches made it to the mailing list. However 
the problem is not yet solved on our AP, and while we are still working on it, 
I'd like to get your opinions as well.

What we did so far: We have tested Intel and Atheros clients (2-stream) which 
work fine with other Access Points. We have tested various driver versions 
(OpenWRT trunk, OpenWRT with manually backported drivers from latest wireless-
testing, including Sujiths latest patches). We have also tried different 
hardware samples. We experience the described problem in all of these 
combinations, ath9k/minstrel tops out at MCS12/13 maximum (manual setting 
MCS15 fails as well).

Any ideas and suggestions (also how to debug the problem further) would be 
very much appreciated.

Thank you,
   Simon
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

> On Saturday 23 November 2013 10:37:46 Thomas Hühn wrote:
> > You said that even manually setting MC14 or MC15 as static rate fails. So
> > seems that it is not an issue at the mac layer rather than the phy layer.
> > I had once something similar on ath5k, where the power curves got not
> > properly assigned to high rates. So just in case, could you check if
> > those two high rates do work if you lower the global transmit power to
> > 12 dBm ?
> 
> Thanks for the input. This was tested quite early in the process with
> 5/10/15/20 dBm and didn't seem to affect the throughput in a positive way.

Anyone any other ideas? :)

Today we've tried another round of the latest OpenWRT + pending patches from 
the ath9k mailing list, but still no change. We'd appreciate your ideas a lot. 
:)

Thanks,
Simon
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

Hey Adrian,

> On 29 November 2013 09:59, Simon Wunderlich  wrote:
> > Anyone any other ideas? :)
> > 
> > Today we've tried another round of the latest OpenWRT + pending patches
> > from the ath9k mailing list, but still no change. We'd appreciate your
> > ideas a lot.
> > 
> > :)
> 
> 9.5.3.15 works fine, right? Do you have the source for it?

Yes, it works fine, or at least much better than ath9k in its current state. We 
don't have the source for Atheros drivers, it was part of the original firmware 
which was installed on these devices. We have asked if the vendor modified 
anything to "tune" for these particular devices, and that would be: disabled 
RTS/CTS, increased beacon interval, disabled beamforming. This didn't give us 
any clue why we have problems in ath9k, though 
> 
> I'll go hit up QCA people (under NDA, of course! :) to see if I can
> get this particular LSDK version and see what particular hacks are in
> for this driver version.

Thanks a lot for your help! :D

Cheers,
Simon
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

> Well, did you try disabling RTS/CTS and increase the beacon interval?

Yep, we tried both but that didn't make any difference.
> 
> TxBF isn't implemented in ath9k, so it's fine.

Yup, we didn't find that in the driver, so it's good that you confirm that. ;)

I guess these "tunings" were not adressing our problems, but the problem 
wasn't present in the proprietary driver to begin with.

Thanks,
   Simon
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] IBSS can't beacon after rejoin / regression in TSF syncing code?

[Simon Wunderlich]

Hi Sujith and list(s),

we have found a regression in the IBSS creation/joining part of mac80211 which 
is appearently connected to the TSF-syncing patches introduced last year[1]. 
It prevents beaconing of an adhoc member after rejoining a cell when this cell 
is currently empty. The problem is present in at least 3.10 and 3.13.

To reproduce, use two adhoc peers and let them join/leave in the following 
order:

station 1: join
station 2: join
station 2: leave
station 1: leave
station 1: join

now we would expect that station 1 sends beacons, but it doesn't. After 
inspecting the code, station 1 actually selected the "old" ibss network and 
waits for a beacon to sync the tsf which is never received, as all members 
already left the network. An easy workaround is to set the IBSS creator always 
to true.

Since this kind of "race condition" could be solved in various ways, e.g. a 
timeout in ibss code, timeout in ath9k, ... i'd like to hear your opinions or 
ideas how to fix it.

Thanks,
Simon


[1] mac80211: Notify new IBSS network creation 
(c13a765bd96f4e2f52d218ee6e5c0715380eeeb8)
ath9k: Fix IBSS joiner mode (1a6404a1d8497692f31808319d662c739033c491)

[2] actual commands I used:
iw dev wlan0 ibss join "rejointest" 5180 HT40+ fixed-freq 02:de:ad:be:ee:ef
iw dev wlan0 ibss leave

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] IBSS can't beacon after rejoin / regression in TSF syncing code?

[Simon Wunderlich]

Hello Sujith,

> Simon Wunderlich wrote:
> > we have found a regression in the IBSS creation/joining part of mac80211
> > which is appearently connected to the TSF-syncing patches introduced
> > last year[1]. It prevents beaconing of an adhoc member after rejoining a
> > cell when this cell is currently empty. The problem is present in at
> > least 3.10 and 3.13.
> > 
> > To reproduce, use two adhoc peers and let them join/leave in the
> > following order:
> > 
> > station 1: join
> > station 2: join
> > station 2: leave
> > station 1: leave
> > station 1: join
> > 
> > now we would expect that station 1 sends beacons, but it doesn't. After
> > inspecting the code, station 1 actually selected the "old" ibss network
> > and waits for a beacon to sync the tsf which is never received, as all
> > members already left the network. An easy workaround is to set the IBSS
> > creator always to true.
> 
> The race condition is that station-1 (the creator) removes station-2 only
> after a while, based on the expiration/inactive timer.
> 
> The small window that IEEE80211_IBSS_MERGE_INTERVAL introduces when
> ieee80211_ibss_disconnect() is called causes the race, since we assume that
> station-2 is still active and do not remove the BSS from cfg80211.
> 
> I am not sure why we have to keep the BSS around when we are leaving the
> network.
> 
> Is this patch the right approach ?

Thanks for the prompt answer!

Yeah, this patch works for my case. I'm not completely sure why we only unlink 
for this special case (no stations & bssid = zero), I don't see why it would 
hurt to always throw away that BSS and rescan on the next join?

I'm CCing Teemu, who introduced this roughly 3.5 years ago ("mac80211: remove 
BSS from cfg80211 list when leaving IBSS", 
5ea096c0c85e80335889539899af9a4717976e0b) , maybe he can explain it more.  I 
couldn't understand that from the commit message and the corresponding mail 
thread.

If we don't hear anything or there aren't any further objections, I think we 
can clean this patch and merge it. :)

Thanks a lot!
 Simon

> 
> diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
> index 771080e..e1688cd 100644
> --- a/net/mac80211/ibss.c
> +++ b/net/mac80211/ibss.c
> @@ -688,17 +688,18 @@ static int ieee80211_sta_active_ibss(struct
> ieee80211_sub_if_data *sdata) return active;
>  }
> 
> -static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata)
> +static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata,
> bool leave) {
>   struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
>   struct ieee80211_local *local = sdata->local;
>   struct cfg80211_bss *cbss;
>   struct beacon_data *presp;
>   struct sta_info *sta;
> - int active_ibss;
> + int active_ibss = 0;
>   u16 capability;
> 
> - active_ibss = ieee80211_sta_active_ibss(sdata);
> + if (!leave)
> + active_ibss = ieee80211_sta_active_ibss(sdata);
> 
>   if (!active_ibss && !is_zero_ether_addr(ifibss->bssid)) {
>   capability = WLAN_CAPABILITY_IBSS;
> @@ -765,7 +766,7 @@ static void ieee80211_csa_connection_drop_work(struct
> work_struct *work)
> 
>   sdata_lock(sdata);
> 
> - ieee80211_ibss_disconnect(sdata);
> + ieee80211_ibss_disconnect(sdata, false);
>   synchronize_rcu();
>   skb_queue_purge(&sdata->skb_queue);
> 
> @@ -1721,7 +1722,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data
> *sdata) {
>   struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
> 
> - ieee80211_ibss_disconnect(sdata);
> + ieee80211_ibss_disconnect(sdata, true);
>   ifibss->ssid_len = 0;
>   memset(ifibss->bssid, 0, ETH_ALEN);
> 
> 
> Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] IBSS can't beacon after rejoin / regression in TSF syncing code?

[Simon Wunderlich]

> I'm CCing Teemu, who introduced this roughly 3.5 years ago ("mac80211:
> remove BSS from cfg80211 list when leaving IBSS",
> 5ea096c0c85e80335889539899af9a4717976e0b) , maybe he can explain it more. 
> I couldn't understand that from the commit message and the corresponding
> mail thread.
> 
> If we don't hear anything or there aren't any further objections, I think
> we can clean this patch and merge it. :)

Nokias mailserver just told me that Teemus e-mail address isn't registered, so 
I guess we shouldn't wait for him. :)
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel