> But why have a special case for hub/hcd use that is different from the > drivers? If a driver wants to grab a device, it should be able to use > it until it decrements the count.
Yes, but drivers are also required to stop using the device completely when they return from disconnect() processing for its interface. At that point they've stopped using it, and decremented the refcount so that their contribution is zero, but the count itself is nonzero ... just like before probe(). Drivers are never the first to increment a count, or last to decrement. (Unless they've got significant bugs...) We know that because khubd (or root hub init) create all devices and initializes their count ... and khubd (or root hub shutdown) are likewise responsible for cleaning up all the device state. Since they do so only after disconnect()ing all drivers, there is no legitimate way anyone else could hold that last reference. > Now granted that usage could just > spit back errors from the hcd, as the device is no longer present, but > it would still be valid. In what sense would it be "valid" though? It wouldn't be connected to any hub; I/O to it couldn't work; HCD state has to have been purged; even the address may have been reused already. Some other device may even have been connected to that hub port. There's a lot of state associated with devices ... which parts would you still expect to be valid in such cases, after some driver doesn't do its disconnect() processing correctly? I see this as enforcing a basic integrity/synchronization constraint. If disconnect() for some driver is broken, so it's still trying to use a device after it's disconnected, I see no reason to do anything other than report this for the BUG() that it is. The line has to be drawn somewhere, and that seems like the natural place. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel Sponsored by http://www.ThinkGeek.com/
