On Wed, Nov 28, 2012 at 05:26:14PM +0100, Johannes Berg wrote:

quoted

quoted

quoted

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.

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

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"

quoted

 * 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 format all the time. Maybe some ath9k fellow can comment
on that, or if they like the debugfs-only idea. :)

Thanks again,
	Simon