[ath9k-devel] [PATCHv2 2/3] mac80211: mesh power save doze scheduling

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2013-02-25 at 11:06 +0100, Marco Porsch wrote:

> > This is strange, why bother with the else if there's a continue?
> 
> I don't quite get this comment. The current logic is like this:
> 
> if (unrelated cases) {
> 	continue;
> } else if (related and blocking) {
> 	allow = false;
> 	break;
> } else if (related, non-blocking and new minimum) {
> 	min = sta->nexttbtt;
> }

Yeah I guess I don't see why it's not just

        if (unrelated cases)
        	continue;
        
        if (related & blocking) {
        	allow = false;
        	break;
        }
        
        if (...)
        	min = ...
        
but it really doesn't matter much.

> >> +               } else if (test_sta_flag(sta, WLAN_STA_MPS_WAIT_FOR_CAB) ||
> >> +                          test_sta_flag(sta, WLAN_STA_MPSP_OWNER) ||
> >> +                          test_sta_flag(sta, WLAN_STA_MPSP_RECIPIENT) ||
> >> +                          !timer_pending(&sta->nexttbtt_timer) ||
> >> +                          time_after(jiffies, sta->nexttbtt_jiffies)) {
> >
> > Are you sure jiffies are good enough? Some systems have HZ=33 or so I
> > think, which makes a jiffy like 30ms.
> 
> Hm, jiffies is what I have available easily. Using the TSF would be 
> obvious but may suffer from delay when obtaining it. Umm... hrtimers again?

I really don't care about your messed up timing stuff here, just
saying :)

johannes