On Fri, 7 May 2004, David Brownell wrote: > Alan Stern wrote: > > > And I can't help thinking that locktree is overkill for almost all cases. > > Can you name any problems that it solves? > > Maybe lock_port() would be a better name, actually. > > Consider some cases where subtree B is a descendent of A. > It'd prevent suspending B while resume notifications were > still being issued somewhere in A ... including potentially > part of B.
If the resume notifications are for a subtree of A that is disjoint from B this isn't a problem. Otherwise, it would mean two processes were simultaneously trying to suspend and resume the same set of devices! The normal locking and state-checking should prevent that. > (In fact there should be ~10 msec delays between > suspend and resume actions ... a per-tree timer.) Likewise, > suspending B while disconnect processing was being done on A, > or even while the A hub was being reset. That's not a problem either. If A is unplugged then operations on B will fail and eventually B will be disconnected. Likewise when A is reset. > Right now it's only used in the suspend/resume logic, but > such issues aren't going to stay uncommon as more tasks start > to manipulate usb tree state from userspace. And the hub > code has pretty much been ignoring a lot of those issues, > getting away with it because the only tree operation Linux > has supported so far has been disconnect (which has been > annoyingly error prone...) and most disconnects are on > degenerate trees (just one device). I suspect most of these things will cause no difficulty; they will simply fail in a natural way. > Actually, suspend during probe needs to be supported. It's an OTG > protocol. Connect A-Host and B-Peripheral together; that's normal > USB. The A-Host notices that the B-Peripheral isn't a supported one > (not in the "Targeted Peripheral List") ... the natural way to do > that is to have a driver matching all devices, and checking them > against that list during probe(). > > Since A can't be the host with B, the problem MAY be just that > B needs to be the master ... so the natural response is to have > that probe() routine invoke the "Host Negotiation Protocol" (HNP) > and switch roles, to A-Peripheral and B-Host. That involves > setting the USB_DEVICE_B_HNP_ENABLE feature in B-Peripheral, > then suspending (to initiate HNP). During probe()... Yes, that's okay. What I was talking about before was one process suspending a device while another process was probing an interface on that device -- that's not good. However, a suspend call made from _within_ probe() should be all right. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
