On Wed, 2009-01-07 at 17:49 +0200, Kalle Valo wrote: > > + * First, it can support hardware that handles all powersaving by > > + * itself, such hardware should simply set the %IEEE80211_HW_SUPPORTS_PS > > + * hardware flag. In that case, it will be told about the desired > > + * powersave mode regardless of association status, and the driver or > > + * hardware must take care of enabling/disabling powersave depending on > > + * the association status and TIM bit and send nullfunc frames by > > + itself. > > Actually I'm not aware of any hardware designs which enables and > disables power save according to association status (modulo fullmac > design, of course). Even iwlwifi, which I think has the most > sophisticated power save support, requires the host to enable power > save according to the association status. Hence I would like to have > the power save enable/disable logic based on association status in > mac80211. Yeah, good point. But iwlwifi is confusing me ;) Since iwlwifi is the only user, I'll clean that up along with cleaning up iwlwifi, would you mind leaving it as-is, and I'll fix it in the short term? > We already have this support in ieee80211_set_associated() > > [Reads the function again] > > Or, actually we had it. I think Vivek's patch changed the > functionality. But anyway, it's very easy to add the support back. > > The reason why I would like to have this in mac80211 is to avoid > having duplicate bugs in different drivers and make the driver > implementation easier. Makes sense. > > + * Additionally, such hardware may set the %IEEE80211_HW_SUPPORTS_DYNAMIC_PS > > + * flag to indicate that it can support dynamic PS mode (see below). > > + * > > + * Other hardware designs cannot send nullfunc frames by themselves and > > + * need to be told explicitly about powersave transitions depending on > > + * association status, need software support for parsing the TIM bitmap > > + * and can implement dynamic PS mode in software. This is also supported > > + * by mac80211 by combining the %IEEE80211_HW_SUPPORTS_PS and > > + * %IEEE80211_HW_PS_NULLFUNC_STACK flags. > > stlc45xx (and p54spi) wakeup for multicast frames automatically, but > ath5/9k need the host to do it. I think we will need a separate flag > for that, but I can add it later. Good point, we need to add that later. > > @@ -858,8 +861,17 @@ static int ieee80211_ioctl_siwpower(stru > > if (wrq->flags & ~(IW_POWER_MODE | IW_POWER_TIMEOUT)) > > return -EINVAL; > > > > - if (wrq->flags & IW_POWER_TIMEOUT) > > + if (wrq->flags & IW_POWER_TIMEOUT) { > > + /* > > + * dynamic PS only supported if nullfunc handling in stack > > + * or hardware supports dynamic PS itself > > + */ > > + if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_DYNAMIC_PS) && > > + !(local->hw.flags & IEEE80211_HW_PS_NULLFUNC_STACK)) > > + return -EOPNOTSUPP; > > + > > timeout = wrq->value / 1000; > > + } > > Actually there are hardware designs which don't have dynamic power > save but have null frame creation in firmware (and hence don't need > IEEE80211_HW_PS_NULLFUNC_STACK). So IEEE80211_HW_SUPPORTS_DYNAMIC_PS > and IEEE80211_HW_PS_NULLFUNC_STACK are not related to each other in > any way. I suspect at76_usb is such design, but I need to recheck > that. But if they don't have dynps but nullfunc in firmware then we can't support dynamic ps at all, can we? > So I would like to implement this so that if > IEEE80211_HW_SUPPORTS_DYNAMIC_PS is not set mac80211 will always use > it's own timer, independent of IEEE80211_HW_PS_NULLFUNC_STACK. If you > agree, I can create a separate patch for this. Oh, I see now, so the firmware just creates the nullfunc whenever you tell it to? bit strange, I guess. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part