On Saturday 29 November 2008 13:21:33 Johannes Berg wrote: > On Sat, 2008-11-29 at 13:15 +0100, Christian Lamparter wrote: > > > > Unless we want to defer RX packet processing to a workqueue rather than > > > a tasklet? > > > Hmm, but if we put the RX packet processing into a workqueue, we have to > > put the tx status report processing in one too (see comment about rx/tx race > > in main.c line 400)? > > Yeah, probably. I don't know all the details all the time, so I write > such comments ;) > > > Or do you mean I should only put ap_sta_ps_end (& ap_sta_ps_start) > > resending stuff into a workqueue? (Yeah, this makes a lot more sense, > > and might actually work!, well let's prepare another patch) > > No idea! > > The only thing I was thinking is that it's not a good plan to have a > callback that has different locking requirements depending on a > parameter. yeah... go back to the extra sta_notify_ps callback approach? I tried to do this with workqueues, but It turned out that queue_work doesn't work since we disabled the irqs in the rx path. ( http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-02/3350.html has a story about the bitter consequences of queue_work & irq_disabled) Regards, Chr -- 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
