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
signature.asc
Description: Digital signature
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
