On Wed, 2014-01-15 at 09:55 -0800, Thomas Pedersen wrote: > >> + if (!hrtimer_callback_running(&data->beacon_timer.timer) && > >> + !test_bit(TASKLET_STATE_RUN, &data->beacon_timer.tasklet.state)) > >> + tasklet_hrtimer_cancel(&data->beacon_timer); > > > > That test_bit() really seems suspicious - there are no other users in > > the tree except for the internal tasklet code... What are you trying to > > do? > > I'm trying to avoid calling tasklet_hrtimer_cancel() recursively, that > is, when mac80211_hwsim_beacon_sched() is called from within the > hrtimer tasklet itself. Looking at it again this does seem ugly. Would > it be acceptable to pass a flag to _beacon_sched() indicating whether > a reschedule is taking place from within the tasklet? That seems fine to me. > We could also > have a mac80211_hwsim_beacon_sched() (which would cance the hrtimer > tasklet) and __mac80211_hwsim_beacon_sched() pair, but I'm not sure if > that nomenclature applies here. Whichever causes less code duplication? Could one call the other maybe? Dunno, up to you. I was really just thinking that the test_bit() was odd since nobody else uses it. 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
