On Mon, 5 Jan 2004, David Brownell wrote:
> > I'm not sure what you mean here. Why do you expect I/O on child devices
> > to start quiescing quickly? More likely you'll see a flurry of error
> > notifications and retries. Eventually things will die down, but you
>
> 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.
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.
> > 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.
> > Until you have some of telling whether a driver-model pointer points at a
> > usb_device or at something else, there doesn't seem to be any good way to
> > do this.
>
> Shouldn't something like this enumerate all hub devices? The
> thing is, we know that drivers only bind to interfaces; and
> of course, that hub devices only have one interface.
>
> struct usb_interface *intf;
> struct usb_device *udev;
>
> list_for_each_entry (intf, &hub_driver.devices, dev.driver_list) {
> udev = interface_to_usbdev (intf);
> ... do whatever ...
> }
>
> That obviously doesn't compile, but that's the way the driver model
> keeps such lists. Device drivers should avoid duplicate lists.
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). I
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
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_
doesn't give you a way to tell which port the child is connected to.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
