On Mon, 2010-10-04 at 11:04 -0700, Luis R. Rodriguez wrote: > On Mon, Oct 04, 2010 at 09:39:52AM -0700, Johannes Berg wrote: > > On Mon, 2010-10-04 at 09:36 -0700, Luis R. Rodriguez wrote: > > > > > > > +wait: > > > > > wk->timeout = jiffies + IEEE80211_ASSOC_TIMEOUT; > > > > > run_again(local, wk->timeout); > > > > > > > > But you'll be staying off-channel for the wait period, so what does this > > > > really help? > > > > > > I totally missed this what locks us offchannel here, I though we just re-arm > > > the timer, and come back offchannel at a later time. What is it that locks > > > us offchannel until the timer runs again? > > > > I believe we stay off-channel as long as the work item is active, after > > it has been activated, no? > > Well I don't see that, the problem here was the assumption that within a work > item we can try to transmit a frame for our home channel without changing it. Yes, that's true, but we do try to stop most things ... we just miss some :-) > If that is desired we must move back to the home channel as I did, but I can > see how we'd need more work than what I did, we'd need to start the queues, > get out of PS state with the AP and then TX... unless TX already handles > that for us. We don't need to go out of PS state to just TX, but we'd need to be careful to TX with asleep bit. That said, we don't TX data frames then. > ieee80211_work_work() just iterates over all work items, and then bails out. > The work loop is protected against local->mtx, and if we call work_work > when we either add new work, purge work, or hit a timer. We *try* to prevent > frames from being sent on the home channel by calling > ieee80211_offchannel_stop_station() but notice how we only stop the queues > for NL80211_IFTYPE_STATION interfaces. No, we just stop the station ones differently from all the others. > Also this seems buggy, we do not take into consideration how much offchannel > work we are doing in consideration against the current AP's DTIM interval as > we do when going offchannel for scan work. We should merge that code for > this offchannel work_work loop. True, we don't do _any_ timing here. 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
