On 12/08/2009 05:02 AM, Michael Buesch wrote: > Did you test this? I think it can't work. > mac80211's suspend calls stop operation before rtl8187_suspend() is run. So the > actual suspend operations runs without suspend flag set. > I think setting a flag is wrong. I also did that mistake in the broadcom driver > and it's wrong. IMO the LED register/unregister code must be completely removed > from the start/stop suspend/resume and hibernate paths. Instead the LEDs must be > registered at device attach phase (that's where the device is registered to mac80211). Yes, I did test this. Thus far, I have done 10 suspend to disk/resume cycles without any problems. That is not a lot of cycles, but I got the warning every time before this patch, and none since. In this section, we also have to worry about kernel panics during rmmod or device removal. The new changes have survived about 400 rmmod/insmod cycles, and 20 device removal/reinsertion tests. As part of the suspend/resume testing, I added printk() statements at the entry to the new suspend routine and the corresponding routine in mac80211. In my tests, the mac80211 routine was called first only one time. In all other cases, the call to the rtl8187 routine was logged first; however, I don't think that matters. The critical part is that the flag be set to prevent queuing another LED on/off task. I will see if I can move the LED register/unregister calls as you suggest. Larry -- 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
