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
--
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
