On Thu, 29 Apr 2004, David Brownell wrote: > This is the kind of thing I meant earlier, when I mentioned that > the basic policy for usbdev->serialize would be to own it when > manipulating children. Follow that policy and those things WILL > be safely serialized ... if they were being done with different > hubs, "safely" would include one running on each CPU! > > In the case of khubd, "children" includes both usbdev->children[] > and their physical incarnations, ports. For all devices, "children" > includes the interfaces, to which drivers are likely bound.
I interpreted "children" to mean just usbdev->children[], not ports. If you allow it to include the ports as well, you rule out the possibility of manipulating different ports simultaneously. I admit that doesn't come up very often, but do you really want to prevent it entirely? Furthermore, you completely rule out the possibility of doing device resets. Since the caller of usb_reset_device() already owns the device's lock, the routine _can't_ acquire the parent hub's lock -- that would mean getting them in the wrong order. > > A slightly less bizarre example is this. When usb_reset_device() is doing > > its port reset, the hub will set the PORT_STAT_C_RESET bit. If the timing > > works out, khubd will notice this during its periodic status polling. As > > it happens, this isn't such a bad case -- khubd will merely tell the hub > > to turn the status bit off -- but it violates the principle that only one > > thread should affect a port at a time. > > Only if you assume it isn't locking. The hub status changes are > queued to khubd, which should be grabbing usbdev->serialize... I've been assuming it shouldn't, for the reasons given above. > > What if the hub is suspended? No doubt you can come up with other > > questions in addition. > > Disconnecting a suspended hub wouldn't be different from any other > kind of disconnect. Drop power to the port, clean up software state. > It'll have no children by then, so nothing else to do -- right? I meant, what if we try to suspend a hub that has activity occurring on some of its ports? A new connection, for example. > I'm more concerned with things like who should suspend()/resume() > the interfaces on devices, and children of hubs. I could live with > the answer being usbcore in both cases. That'd be almost trivial for > interfaces ... but having five layers of external hub suggests to > me that maybe khubd should have a list_head in usb_device, so that > it can work with pre-flattened trees! "Who does suspend/resume" will probably end up involving other parts of the kernel. And it's not clear to me why you prefer a flattened list over a tree. The costs of recursion aren't all that bad, and with a list you would have a hard time maintaining the proper set of locks as you went along. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
