I'm about ready to give up on device reset during probe.
Consider this. There are three different paths that can call a driver's
probe():
1. Newly attached device is configured by usb_new_device().
Both the device and its parent hub are locked.
2. New configuration is installed through sysfs. The device is
locked but its parent hub isn't.
3. Newly registered driver is matched to all unbound USB interfaces.
Neither the device nor its parent hub is locked.
The driver doesn't know (and shouldn't know!) which path has called it,
although if really necessary usbcore could store that information in the
interface structure. (1) is okay, since no additional locks are needed.
(2) is bad since we have to lock the parent, which means acquiring locks
in the wrong order. (Of course, the sysfs code could be changed to lock
the hub as well as the device.) (3) is just a mess in every respect.
And now consider this: Every path calling probe() definitely has acquired
the USB subsystem rwsem. Proper locking order requires that _no_ device
locks are acquired while holding the rwsem!
All told, the easiest thing is simply to rule out device resets during
probe.
Here's another problem (first raised by Oliver). In hub_port_init(), the
failure path simply disables the port. It doesn't check to see that the
disable request succeeded. If it didn't succeed, we potentially have a
device using address 0 on the bus and usb_address0_sem is unlocked. The
way to cope with that is to reset the parent hub. This means calling
hub_reset() while holding the address0 semaphore -- not feasible at all. I
suppose another way to cope would be to disable but not reset the parent's
port (working up the tree if necessary). This would still mean acquiring
locks in the wrong order.
Maybe neither top-down nor bottom-up locking is workable. Maybe the best
approach is to have a single bus-wide semaphore, and only allow one
significant action to happen at a time. That would simplify a lot of
problems. (Even the newly-registered driver problem, although that would
require locking _all_ the buses.)
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
