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 format all the time. Maybe some ath9k fellow can comment on that, or if they like the debugfs-only idea. :) Thanks again, Simon
Attachment:
signature.asc
Description: Digital signature
