Re: [PATCH] mac80211: redefine usage of the mac80211 workqueue

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Sat, Jul 25, 2009 at 1:35 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-24 at 20:47 -0400, Luis R. Rodriguez wrote:
>> The mac80211 workqueue exists to enable mac80211 and drivers
>> to queue their own work on a single threaded workqueue. mac80211
>> takes care to flush the workqueue during suspend but we never
>> really had requirements on drivers for how they should use
>> the workqueue in consideration for suspend.
>>
>> We extend mac80211 to document how the mac80211 workqueue should
>> be used, how it should not be used and finally move raw access to
>> the workqueue to mac80211 only. Drivers and mac80211 use helpers
>> to queue work and flush the mac80211 workqueue:
>>
>>   * ieee80211_queue_work()
>>   * ieee80211_queue_delayed_work()
>>   * ieee80211_flush_workqueue()
>
> I would prefer to have wait_on_work()

That's currently static.

> and/or cancel_work_sync() instead
> of flushing?

That's fine but currently drivers are issuing flush_workqueue() directly.

> It's often preferable due to locking constraints to
> cancel_work_sync() instead of flush_workqueue(). Do people really need
> flush_workqueue()?

Yeah good point, so I see 2 users of flush_workqueue, one in at76 and
another on ar9170.

at76: at76_delete_device()

This is used at usb disconnect and probe failure. cancel_work_sync()
definitely seems more appropriate.

ar9170: ar9170_op_stop()

same here, but seems we could add the flush on mac80211 prior to
calling the drv_stop() currently we call it after.

  Luis