On Thu, 21 Apr 2011, Paul Stewart wrote: > > The driver needs better coordination between open/stop and > > resume/suspend. The interrupt and receive URBs are supposed to be > > active whenever the interface is up and not suspended, right? Which > > means that usbnet_resume() shouldn't submit anything if the interface > > isn't up. > > How do we define "up" here (from a network perspective there are many > ways to interpret that)? How does this concept compare to the user's > "ifconfig up/down" state? I don't know the details of how network drivers are supposed to work. But it doesn't matter -- for your purposes you should define "up" to mean "whenever the URBs are supposed to be active (unless the interface is suspended)". > What call do I use in usbnet_resume() to > tell that the interface isn't up? Currently I'm using netif_running() > which responds true in this condition, which is why I'm resorting to > the flag. Again, I don't know. However, the URBs get submitted from within usbnet_open() and killed within usbnet_stop(), right? Therefore you can use any condition which gets set to True in usbnet_open() and set to False in usbnet_stop(). (If nothing else is suitable, use a flag of your own.) And be careful of the edge case: Since usbnet_open() itself performs a resume operation, you need to make sure the resume takes place before the condition becomes True -- otherwise the URBs will get submitted twice. One more thing to keep in mind: If the kernel is built without PM support, the resume and suspend routines will never get called. Therefore they must not be the only places where URBs are submitted and killed. 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
