On Sat, 1 May 2004, Oliver Neukum wrote: > Am Samstag, 1. Mai 2004 17:15 schrieb Alan Stern: > > Instead they can be used by the hub driver to ensure that only one thing > > happens on a hub at any time. When suspending or resetting a port, the > > rule should be to acquire the serialize lock on the child first, then on > > its parent hub. That matches the requirements of usb_reset_device(), and > > the new suspend code can easily be changed to comply. > > But usb_reset_device() can lead to a topology change.
Only indirectly. Although it's not really implemented properly now, what will happen is this: Driver calls usb_reset_device(), which determines that the descriptors have changed. Then usb_reset_device() disables the port, sets a flag to notify khubd, and returns failure. Sometime later the khubd process sees that flag, calls usb_disconnect(), does a port reset, and creates a new struct usb_device. Hence the topology change takes place in the usual place, within khubd, not inside usb_reset_device(). I had thought earlier that disabling the port would be enough, with no need for an extra flag. It turns out that's wrong -- disabling a port does not set the PORT_STATUS_C_ENABLE flag. Only a communications error that causes the hub to disable the port by itself will do that. 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
