On Sun, Sep 9, 2012 at 12:15 PM, Arik Nemtsov <arik@xxxxxxxxxx> wrote: > On Fri, Sep 7, 2012 at 5:54 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >> Do not emit a warning in that case, since there is nothing else in mac80211 >> that would effectively prevent more work from being queued. >> >> Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx> > > This is a bit problematic. You see we rely on this always working > (prior to the suspend handler) to handle the case of HW reconfig > before suspend. > > The better option for wlcore would be to flush the workqueue again > after setting suspended = true, but i'm not sure if it's possible. > > At the very least we'll have to know the work was not queued (via a ret val?). Actually this is problematic in general, as lower level driver use ieee80211_queue_work for day to day stuff, and are not aware of mac80211 state (was pointed out by Eliad). While it makes sense to expect a driver to not queue work after its suspend handler is called, you're doing something quite different here. So adding a retval is not good enough, as it's a big API change for the drivers, that suddenly have to check every queue_work call. Maybe turning this into a freezable wq is a good idea? Maybe just fail works queued from within mac80211? (but that can be done from inside by just checking the quiescing flag inside the work) -- 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
