"Bob Copeland" <me@xxxxxxxxxxxxxxx> wrote: > On Wed, Oct 1, 2008 at 6:34 PM, Elias Oltmanns <eo@xxxxxxxxxxxxxx> wrote: >> "Bob Copeland" <me@xxxxxxxxxxxxxxx> wrote: > >>> On Wed, Oct 1, 2008 at 5:10 PM, Elias Oltmanns <eo@xxxxxxxxxxxxxx> wrote: >> Oh, but it is cleaned up by ath5k_stop_hw(). The issue is a different >> one here: >> >> ath5k_init() == ->start() >> ath5k_stop_hw() == ->stop() >> >> Since the mac80211 layer never opened a device, it won't close it >> either. Thus, ath5k_stop_hw() does not get called on module unload. By >> calling ath5k_init() on resume, the driver has effectively started the >> device when it was not supposed to do so and this event is not being >> tracked by the higher layers. > > Ah, yes, good analysis... and ath5k_init is scheduling the timer. I > doubt ieee80211_opened would fly; probably the better thing to do is > ensure that the cleanup gets called regardless of whether ath5k_stop > gets called (it shouldn't matter since the irqs all get created in > _attach). Not sure I agree there. Why should calibration take place regularly even though the interface appears to be shut down from user-space's point of view? It simply doesn't make sense to start the interface if nobody intends to use it. Not that I know anything about it, but I imagine that periodic recalibration might even be a waste of power, something most laptop users will care about. So, if higher layers won't provide any information about what interface is considered opened, then ath5k has to track this sort of state information itself if it intends to resume to the exact same state of affairs as observed at the time of going into suspend. For all I know, other drivers will have similar issues and track the open state which is why I suggested ieee80211_opened, but you will know much more about these things than I do. Just as an aside, at least on my system the following doesn't work anyway: 1. # modprobe ath5k 2. # ifup ath5k 3. # ping <ap> 4. s2ram 5. resume 6. # ping <ap> The last ping fails with network/host unreachable -- this is with a WPA configuration and I haven't tested anything else. So, at least I always have to make sure that I shut down all interfaces before suspending anyway. Regards, Elias -- 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
