Re: [RFC 0/3] mac80211: fixes for do_stop while suspended

[Stanislaw Gruszka <sgruszka@redhat.com>]

On Wed, Mar 27, 2013 at 11:33:19PM +0100, Johannes Berg wrote:
> I looked at this and I think we should do a bit more restructuring.
> The virtual monitor is unsafe no matter how you look at it, even
> with your second patch, due to channel contexts. I therefore opted
> to just destroy it unconditionally on suspend, and restore it when
> resuming, which has pretty much the same effect to the driver but
> handles channel contexts differently. As we disconnect etc. in all
> other interface types (*), channel contexts should thus be fully
> destroyed on suspend. I should probably add a WARN_ON() for that
> somewhere ...
> 
> I've also restructured the do_stop() function itself so it doesn't
> get "if (local->suspended)" checks all over but has it at just a
> single point at the end of the function before doing all driver
> updates.
> 
> I think this is a good compromise as it makes it obvious that the
> driver updates happen last, and only conditionally. It remains a
> tricky proposition to make sure all other state (like chanctx) is
> actually destroyed correctly, but right now that should indeed be
> the case.
> 
> No doubt I've made some mistakes here, but as I don't own any USB
> devices any more (they all broke) I'd appreciate some testing.

Just tested (with 3/3 v2 patch) and it fixes the test case I have,
that I used to create my patches. Test case is doing suspend with
reverted commit 761ce8c41ed20ee3af77f2df527edc3f92e6f3bf. This make
device is automatically removed/added during suspend, because lack 
of .reset_resume callback.

Than I tested with physical remove device from USB slot while machine
is suspend. This gives warnings in ieee80211_reconfig() and
ieee80211_stop(). I'm not sure why, I'm going to look at that, but
I think this patch set should be applied and some more fixes provided
on top of it.

Stanislaw