Re: [RFC] cfg80211: survey report capability

[Holger Schurig <holgerschurig@googlemail.com>]

> Nit: missing newline

Done


> > +enum survey_info_flags {
> > +	SURVEY_INFO_CHANNEL = 1<<0,
> > +	SURVEY_INFO_NOISE = 1<<1,
> 
> A response w/o a channel seems entirely useless, shouldn't we just
> require a channel?

Hey, libertas could respond just the noise and no channel. But it
could then also respond with the channel, it's there anyway.


> For mBm, an s8 won't be enough I think? -90 dBm == -9000 mBm?

Oh, sure.



> You need to construct a nested attribute here and put the values into it
> so that the callback can be invoked multiple times, once for each
> channel. OTOH, when there are many many channels that will overrun the
> message size at some point and we'll pull our hair (like we're doing now
> with the channel list in phy info) ... so I'd prefer you move this to a
> dump-style model like dump_stations has.

Okay.

Or maybe a little bit more nl80211_dump_scan.



> Right now you're retrieving a single channel but can't even control
> which one.

Idea was to retrieve as many channels as the drivers sends using the
callback.

Controlling what should be returned should be done after either
enhancing scan-trigger or writing a new survey-trigger command. So
survey-dump would be very similar to scan-dump: return as much data as
is available (and not stale).

And this could very well be only one channel. And in absence of
survey-trigger or an enhanced-scan trigger it will certainly only
report info about the current channel.



> Maybe that's useful functionality in addition to dump when you _can_
> ask for information on a specific channel, but that'd have to pass
> in the frequency from userspace.

Would this then be useful for the scan-dump command as well?


> Retrieving all data like you've implemented (though I guess you forgot
> the multiple channels case) should be a dump.

I did not forgot about the multi-channel case, I forgot about the
nesting. /me's still learning nl80211 :-)