On Fri, 22 Apr 2005, David Brownell wrote: > If an IRQ comes in before the root hub is "live" in usbcore, that > would need to behave. It's clearly safe to register while the > HCD has locked things and blocked the IRQ; not clearly safe to > do it later...
An IRQ coming at that time couldn't be a completion interrupt, because no URBs can be submitted before the root hub is registered. It might be an error interrupt or a port-change interrupt. Would the HCD have any trouble handling these? uhci-hcd wouldn't. There is a flag that can be checked if necessary: hcd->rh_registered. In theory an HCD shouldn't care one way or another about whether the root hub has been registered. As Oliver likes to say, it would be a layering violation. The HCD should concern itself only with the hardware. > > Yes. I just don't see any reason for setting the state to CONFIGURED, > > since that's what it should be already. > > It would have been, before the reset. When you reset a device, it > can't stay in the CONFIGURED state. (But maybe details changed since > then...) Maybe they have; it depends on what you mean by "reset". A port reset will change the state, whereas usb_reset_device often won't. However neither of those resets applies to root hubs. I think the reset you're referring to is something internal to ehci-hcd, which doesn't change the root hub's state at all. > > Looking more closely, it appears that hub_set_power_budget does nothing > > but adjust a value that's derived from the hub descriptor in the first > > place. So if the HCDs would report the correct value for bHubContrCurrent > > from the start then nothing more would be needed. > > There'd need to be a special case though; hubs don't have a power budget > unless they're bus-powered. Ergo the awkwardness. Okay, it looks like the best arrangement will be for hub_configure to read the power_budget value for root hubs directly from the hcd structure. No sense messing around with descriptors in nonstandard ways, particularly since the descriptor only allows for power consumption up to 255 ma, which might not be high enough to express the requirements of some controllers. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
