On Thu, Apr 21, 2011 at 11:48 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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.) This is exactly the situation I'm in. I couldn't find any other driver or network state that cleanly represented the stop/start state of the driver. I'll post a new patch that uses an OPEN flag instead of an interrupt halted flag, a GFP_NOIO flag, and kills and frees the interrupt URB on usb_disconnect(). > Â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
