On Mon, 23 Feb 2004, David Brownell wrote: > > There's no reason they couldn't be allowed during the STARTING state. > > The real problem seems to be that the start() method does two things: turn > > on the controller hardware and register the root hub. It becomes tricky > > to change the state in between those two events. > > I can't see them as two separate events. The hardware and its root > hub are synonymous ... if one's running, so's the other. Starting > the controller is an atomic operation, from all perspectives outside > of the HCD.
Okay, let's go back to an earlier point in the discussion. You said that setting state to RUNNING before calling start() might lead to problems with other calls being passed through too early, before the hardware was running properly. So what other calls might get sent through? Nothing will originate from the USB system (enqueue, dequeue, etc.) until the root hub is registered, by which time the controller will be running -- no problem there. Since this is during probe() the PCI bus rw semaphore is write-locked; hence no driver model calls that need to traverse the device tree can take place -- so no release, suspend, or resume. I think all that remains is unwanted IRQs -- and they should be acceptable any time after reset() has finished. Put it all together and there doesn't appear to be a problem. Alan Stern ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
