Hi, > there can be always a situation where this ends up badly. You tell the > hardware that it can sleep now, but then you change your mind because > userspace finally got its act together. Bad luck. Right. > My point here is only that if the hardware needs a certain amount of > time before it makes sense to sleep, it should just tell mac80211 this > and it should be honored. I don't really see how that makes sense though. Why would the hardware "need[] a certain amount of time before it makes sense to sleep"? How would it not make sense to go to sleep whenever possible, right away, however long the hardware needs to actually go to sleep then? Yes, it's possible that the hardware takes a little while to wake up again, but we can only account for that if we can predict when we need to wake up again in the future, but we definitely can't. So yes, while it doesn't make sense to tell the hw we're idle when we will only be idle for 50ms and the hw needs 30 to go into idle and 30 to get out of it, I'm not sure how telling it that it needs 30ms will help mac80211. Going to idle and coming out of it is meant to be synchronous, so mac80211 will always wait for the driver to finish that operation. > The default should be that we try how good the hardware can handle > mac80211 being aggressive with switching to idle. Maybe auth/assoc is a > special case anyway and we should have a sensible timeout value. We > could ask userspace to tell use that value when doing auth, but that > feels kinda ugly to me. Being idle between auth and assoc probably is a special case, yeah. So far iwlwifi has handled it just fine for me though, so I'm inclined to not worry about it too much. Well, with the race fix... johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
