Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Mon, 2008-07-14 at 15:31 +0300, Tomas Winkler wrote: >> This patch makes listen_interval configurable by low level driver. > > I'm not sure we we really want that. Me neither. > With this, you're again putting more features and more decision making > processes with the driver, I would much prefer this to be worked out in > mac80211 so we can do it across all drivers. I was just thinking the same. In my opinion the driver should be as simple as possible, and all the logic should be in mac80211 or, if possible, even in user space. > If this is a knob that should be adjusted then we want to enable users > to do it, and if it isn't then we can put a value into mac80211 and fix > it. Listen interval is very much dependent on the DTIM period and for which beacons firmware wakes up (every beacon, every DTIM beacon, every second DTIM beacon etc). For user space making this decision is very difficult because it would need to know the current DTIM setting and capabilities of the driver/hardware. It will get complicated pretty quickly and I don't see any advantage to push this decision to user space. I think we need to soon come up with an idea what kind of PSM control interface are we going to offer for the user space. Is it going to be very low level (eg. based on listen interval and DTIMs and what not), a higher level (eg. levels from one to five, five being the most aggressive level from powersaving point of view) or what? We have a plenty of options and I think we should discuss about this at the summit. > Having drivers make these kinds of decisions is very bad for uniform > wireless behaviour. I agree. On the other hand different hardware have different ways to configure, and support, PSM so the implementation might get complicated. But still I believe that the driver shouldn't be making this kind of decisions. -- Kalle Valo -- 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
