On Mon, Dec 26, 2016 at 12:50:31PM +0100, Mark Kettenis wrote: > > Date: Mon, 26 Dec 2016 09:13:50 +0100 > > From: Stefan Sperling <[email protected]> > > > > I do not see a good reason for using multiple custom task queues > > in this driver, and at the same time it is using systq for tasks. > > > > This moves all tasks to one custom queue to make things consistent. > > Except I'm leaving the init_task on systq because this task is kind > > of special (e.g. it might be added during resume and I'm not sure > > if that requires IPL_HIGH). > > Perhaps the custom queue would be fine for init_task, too? Not sure. > > Are you certain you don't need work times to be processed while > processing other work items. For example, to process state > transitions while scanning? Using a single taskq could lead to a > deadlock in that case...
I have seen no such issue during testing. This driver does not follow SCAN->SCAN transitions at all. These transitions are triggered by timeouts when the net80211 stack wants to switch channels. Because channel switiching is handled in firmware the driver handles such transitions as a no-op. Sharing a task queue means that event handlers will be run in the same order they were triggered. I hope this might fix some problems such as "could not initiate scan" which some people have been reporting. I have no evidence support this yet, though.
