Hi, > Userspace tends to display a wifi icon with the rssi shown as a > number of "signal bars", usually 4, 5, or 6. It's actually not clear to me that this is really how it should be. There's a point to be made that taking a more holistic "link quality" would be a better choice. That's related, but maybe can be a separate discussion. > and a hysteresis value to be used in the same way as with the > NL80211_ATTR_CQM_RSSI_THOLD attribute, or even modify it to allow > multiple thresholds to be given but that would need a problematic > driver api change. What would be the best way to do that? So ... I don't think there's a good way to do this at all. The problem is that you really want this to be offloaded to the device, *especially* if you care about low power usage, because you absolutely don't want to be processing each beacon (which is typically what we derive the data from today) in the host CPU - you want those to be filtered by the device so you don't wake up the host CPU every ~102ms. Without offloading to the device, your patch is actually fairly much pointless, because you've already woken up the host CPU, at which point punting to userspace probably isn't all that much more expensive over the cost of waking up the CPU in the first place. Looking at the code, it seems like only a single driver could support this in a pseudo-offloaded fashion (iwlmvm), where all the others that offload it today would not be able to support this API at all, unless they fall back to complete software processing which, as I wrote above, will have far worse power consumption consequences. Therefore, adding this API just for mac80211 seems pretty pointless, especially since you're targeting this for IoT, where I expect people will be using full-MAC chips rather than soft-MAC, with the consequence of not even using mac80211-based drivers. Oops. > The assumption is that you can't simulate the same behavior with just > the current NL80211_ATTR_CQM_RSSI_THOLD attribute. Is that true? Technically, it seems that perhaps if you wanted to have a few ranges, you could always pick one that's currently active, and program that into the driver/device, with a hysteresis big enough to extend to the edges of the next range, or something? Let's say you're currently sitting at -50dBm, and want your ranges to be -100..-80..-60..-40..-20. Then you could program -50dBm with hysteresis of 10dBm, and it'd tell you when you move below/above? This probably won't really work, the hysteresis probably won't be honoured precisely enough by all drivers. Or we can just fix the drivers, I guess. However, if you're just at the edge of your range, e.g. when your current signal strength is -60dBm, you'd still flip-flop in and out of that range continuously, although userspace could just program a different threshold/hysteresis for those cases as well. Anyway, not sure this can be made to work, and drivers would play ball. Nevertheless, somewhere along these lines we could probably make things work better than hard-coding the kind of assumptions you have in your patch. Perhaps by extending this to know about low/medium/high, which a number of drivers seem to support, so that you can program -60,-40 (with some appropriate hysteresis) and then get a signal when you move out of that range towards low or towards high. When that's stable enough, you can then dynamically reconfigure to the next range. johannes
