On Mon, Sep 19, 2011 at 3:05 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2011-09-19 at 08:09 +0300, Luciano Coelho wrote: >> On Sun, 2011-09-18 at 15:03 +0300, Eliad Peller wrote: >> > In some cases the driver might want to change the >> > default dynamic ps timeout (e.g. coex activity adds >> > latency to the rx/tx path, which might result in >> > redundant psm entrance). > >> Let's see what Johannes is going to say about this change in mac80211, >> but IIRC this timeout used to exist with WEXT, but it was not >> implemented in nl80211. We (at Nokia, probably Juuso) tried to >> implement it a long time ago, but after some discussions with Johannes, >> it was decided that this value wouldn't be settable from userspace at >> least. I don't know if it was considered setting it from the driver >> side, though. > > Yeah it's a good question ... but in this case there actually is some > actual reason for it -- I think it's probably used for BT coexist? > Obviously the user can't make an informed choice in that scenario, but > the device might actually be able to? My biggest objection back then was > that the user has no real reason to play with it, and the latency > properties of it are better done in other ways. > i agree. however, note that the network_latency can only set the dynamic ps on/off. it can't control the timeout. > Which actually makes me think that having a completely fixed value from > the driver might not be a good thing? I mean, yes, we allow wext to > override it, but really we want this to be controlled by the latency > requirements I think. That's obviously something of a pipe dream right > now since nothing seems to ever use that, but ... > > So anyway, do we really want this to be completely fixed by the driver? > Maybe a range would be better? > i guess it might be better. but as it doesn't have any real use, and the code is over-complicated anyway, i think we can leave it for now :) Eliad. -- 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
