As soon as you mark the device as USB_STATE_NOTATTACHED, there will be no more retries ... completions happen at whatever rate protocol timeouts kick in, but from then on there's no way to start new I/O. Like a car running out of gas, with no hills.
Ah, but devices aren't marked as USB_STATE_NOTATTACHED until usb_disconnect(), in its recursive way, begins handling them. That's part of shutdown processing by my lights -- the other parts (disabling endpoints and unbinding drivers) are part of usb_disconnect() as well.
Sure, that routine handles that stuff today. But it's already the part that already gets handled first ... and it's the part that should get handled before, as we'd previously discussed, the other parts get queued up for some other task/thread.
After all, if we were to do what I suggested earlier and defer shutdown processing to another thread, that thread would essentially do nothing but call usb_disconnect().
Perhaps what you're intimating is that as an initial immediate part of detecting a disconnect, we should set the states of all the devices in that subtree to USB_STATE_NOTATTACHED? Doing that would mean acquiring the serialize semaphores, so it wouldn't really be immediate.
I thought I was doing more than intimating ... I thought I'd actually described that earlier when I described splitting the disconnect processing up! (Or maybe that got edited out somewhere. I'm quite certain I've written more than once about marking that transition ASAP.)
Re locking, current code doesn't grab that semaphore before updating that state; but it could be grabbed and released, if necessary.
shouldn't expect them to stop until the drivers have been notified that their device has disconnected -- and that is part of the shutdown processing! The only way to make things stop ASAP is to run the disconnect (shutdown) processing ASAP.
Depends what level of "stop" you're talking about.
- NOTATACCHED ... no new I/O started - endpoint fully disabled ... all old I/O stopped - after all disconnect()s ... all i/o contexts stopped using it
Any level. None of those changes take place until usb_disconnect() runs, and when it's done they have all taken place.
And that was something I described changing -- with NOTATTACHED done first when the port disconnect is noticed, then some task handling the disable() and disconnect() parts.
Regardless, device drivers would see those stages, at whatever rate they happen to notice. The code handling the disconnection (currenly all in usb_disconnect) does sleep, so those drivers have plenty of opportunity to notice the intermediate stages even on uniprocessor systems.
list_for_each_entry (intf, &hub_driver.devices, dev.driver_list) { udev = interface_to_usbdev (intf); ... do whatever ... }
That would enumerate all the hubs provided there's only the one hub driver
(a pretty safe assumption since the driver is built into usbcore).
Not an "assumption", really; more something at the level of an architectural constraint. You can even see it written in the USB spec. The hub driver is part of the "usbd" (which is what Linux calls "usbcore", more or less).
suppose you could say that any given device is a hub iff its first interface is bound to the hub driver. You could also, in a somewhat
Again, this is in the USB spec. Hubs have only one interface. Both the interface and device classes will say "hub".
fragile way, decide that a driver-model child of a hub device is another usb_device iff it isn't the interface's embedded device. That _still_
Or if it's not owned by the hub driver. I'm not sure why you say "fragile" though.
doesn't give you a way to tell which port the child is connected to.
True, but that wasn't the question I was responding to either!
We'd already agreed that something else would need to record that information, if dev->children goes (and isn't replaced by hub-private data). One solution often used with similar problems is to have the child record its index in the parent.
- Dave
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
