On Wed, Apr 20, 2011 at 2:08 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 19 Apr 2011, Paul Stewart wrote: > >> Set a flag if the interrupt URB completes with ENOENT as this >> occurs legitimately during system suspend. When the usbnet_bh >> is called after resume, test this flag and try once to resubmit >> the interrupt URB. > > No doubt there's a good reason for doing things this way, but it isn't > clear. Why wait until usbnet_bh() is called after resume? Why not > resubmit the interrupt URB _during_ usbnet_resume()? Actually, I was doing this in the bh because of feedback I had gained early in this process about not doing submit_urb in the resume(). If that issue doesn't exist, that makes my work a lot easier. In testing I found that just setting this to happen in the bh might be problematic due to firing too early, so this is good news. > This would seem > to be the logical approach, seeing as how usbnet_suspend() kills the > interrupt URB. Aha! But you'll see from the current version of my patch that we don't actually ever kill the interrupt URB. It gets killed all on its own (by the hcd?) and handed back to us in intr_complete(). This last bit about the complete function being called was lost on me for a while which is why in a previous iteration of the patch I was trying to kill the urb in suspend(). > For that matter, where does the interrupt URB get deallocated? It > obviously gets allocated in init_status(), but it doesn't seem to be > freed anywhere. That's a very interesting question and one that I noticed as well. I was going to tackle that as a separate issue. > > Alan Stern > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
