On Mon, 2010-04-19 at 16:43 +0200, ext Johannes Berg wrote: > On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote: > > Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos > > network latency configuration, configure a default value of -1 as the dynamic > > ps timeout in cfg80211. This value allows the mac80211 to determine the value > > to be used. > > > > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx> > > --- > > net/wireless/core.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/net/wireless/core.c b/net/wireless/core.c > > index 6ac70c1..37d0e0a 100644 > > --- a/net/wireless/core.c > > +++ b/net/wireless/core.c > > @@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb, > > wdev->ps = true; > > else > > wdev->ps = false; > > - wdev->ps_timeout = 100; > > + /* allow mac80211 to determine the timeout */ > > + wdev->ps_timeout = -1; > > if (rdev->ops->set_power_mgmt) > > if (rdev->ops->set_power_mgmt(wdev->wiphy, dev, > > wdev->ps, > > Does that need some API doc updates to indicate, as part of the cfg80211 > API, that -1 means some way of setting it by default? > > Or actually, wouldn't it make sense to move the pm_qos logic here (into > cfg80211)? I thought about that but then I realised that would contradict with one of the arguments presented against the dynamic ps API I proposed earlier. The argument specifically stated we don't want the API as in the future there will be some uber-cool psm implementations in some (full-mac?) chipsets that don't even use a value like this. Therefore I opted to leave the implementation in mac80211, thinking that the entire configuration option will be removed from the cfg80211 once the wext is gone. -Juuso > 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
