> Pardon a dumb question, but can filtering be turned off? I doubt > anyone would want to, but just wondering.
Generally I assume that a typical device/firmware will be able to turn it off (I know ours can), but we don't think we even provide a knob for it for anyone to request it, so you'd have to modify the driver. > Is there anything you have in mind? Our goal is to minimize > hardware-kernel-userspace wakeups. With the nl80211 API as it is > today, it doesn't seem feasible to do anything besides > polling. Whatever we come up with will surely be better than that. I was thinking of just providing two thresholds, since you should be able to emulate more of them with that, without much cost. > So you're thinking of having high and low threshold. So we'd get an > event when we're higher than the high threshold and lower than the > low threshold, right? I'm mostly handwaving, but yes. > Then we'd need to bootstrap our current rssi somehow, or do we get > another event? I'm guessing we're going to have some race condition > issues? Generally, with CQM, when you initially program it you get an event telling you where you're at right now - so hopefully you'd get "middle" (rather than "low"/"high") with the actual signal falling squarely into your range, and from there on you're pretty much good to go. > Would using an n-threshold API be possible? That way user space can > program in whatever threholds once, and then the kernel would figure > out how to support that given the relevant hardware capabilities. That seems like a reasonable idea. We'd want to have code in cfg80211 that does the emulation as we discussed above, so that from a userspace POV an "arbitrary" number of thresholds is supported (if the capability is supported at all, which would depend on the device doing >=2 thresholds). johannes
