On Thu, 2015-11-05 at 08:42 -0800, Ben Greear wrote: > Grep for 'dwell_time' in ath10k driver dir...it is already using > different values (active 50, passive 150) than what mac80211 does, so > anyone assuming scan time is exactly some duration is already > confused. Sure, you can even grep more carefully and notice that in certain cases iwlwifi/mvm doesn't even have control over the dwell times as they're handled entirely in firmware, and the firmware might do stranger things still. In the future, with FILS, scanning is going to get more complicated and will likely have to jump around channels, hitting each one two or more times. But that's kinda my point - we have lots of different ways to do scanning today. Assuming anything about it, other than that'll eventually return scan results, is pointless. You're arguing though that dwell time should be controllable. This can be a problem: > It wouldn't break clients if the value is known to just be a hint > from the beginning..ie clients cannot ever expect that this value > is guaranteed to be used. Then I fail to see the use-case for this. If there's an actual requirement to do scanning with a changed dwell time, then you really will need to know that it is going to work/has worked. If you don't really care, why would you specify a hint? This isn't really an optimisation that you can safely ignore. It has massive impact on the scan scheduling/timing. > But, if it would help this feature get upstream, then I will work on > adding a driver flag. Would that make it acceptable for upstream? I think you really should more clearly define the use case for this first. If it's just a debug (or similar) thing, why even bother, we can just put it into ath10k debugfs? I'll agree that many of the software implementation are pretty simple today and could implement this fairly easily, but I don't want us to cut off the path towards other things like FILS in the future by using something like this. Especially without a well-defined use-case. Jouni mentioned once to me that there is actually a spec use case for something like that, but I'm not sure if it's really scanning or measurement? In any case, even if that's scanning, it should really be understood to apply to those use cases only, and not be used indiscriminately, since using it will cut off the ability of using current and future optimisations. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
