>> diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
>> index 611d983..73dacbb 100644
>> --- a/drivers/net/wireless/rt2x00/rt2x00.h
>> +++ b/drivers/net/wireless/rt2x00/rt2x00.h
>> @@ -821,6 +822,7 @@ struct rt2x00_dev {
>> /*
>> * Scheduled work.
>> */
>> + struct workqueue_struct *workqueue;
>
> Do you really need a whole workqueue (kernel thread) per device? I would
> think that using schedule_work / cancel_work_sync for this task and keep
> using the mac80211 wq would be sufficient?
True, but this is a quick patch to resolve the bug for sure. I am going to look
into the workqueue handling more closely to see what the impact on splitting
the different work structure over different workqueues is later. I *think* I at
one time made use the assumption that work structures on the same queue
don't run concurrently and I really need to look into that first to see if there
isn't some other locking problem that will appear when I split the work over
2 different queues.
At the moment I am also concerned about the link tuner who runs in the
workqueue and if there isn't any negative side effect regarding the early
flush_workqueue() in mac80211.
Ivo
--
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
