Here is a related matter. This is something I've mulled over for a few months but haven't mentioned before: The hub driver needs to have some way to mark ports as in-use by other threads.
Consider. With the CONFIG_USB_SUSPEND patch, we have the possibility that a user process might be suspending a port, while simultaneously a driver is trying to perform a port reset, and meanwhile khubd is trying to handle a PORT_STAT_C_CONNECTION notification! (Okay, it can't be quite that bad since usbdev->serialize will prevent some of these things from happening together.)
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.
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...
There are ramifications to this. When the hub driver's disconnect() routine runs, should it wait until all the ports are no longer in use?
It's a BUG if khubd() calls it with any ports busy; so no, it should not wait. Everything needs to respect the actual/physical hierarchy.
Right now, the driver model isn't helping out with such stuff, and so one of my questions is whether it should, or someone else should.
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'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!
- Dave
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
