On Monday 28 November 2005 11:30 am, Alan Stern wrote: > On Mon, 28 Nov 2005, David Brownell wrote: > > > But there's a related point, that usb_add_hcd() sequences things in a > > pretty strange order. For one thing, the root hub isn't created at > > the time that misnamed reset/init/setup routine is called ... which > > means that one-time root hub customization must be done elsewhere, in > > some routine that's not for one-time setup. Of course I have a patch > > for that; but that calls for a bit more testing. > > What root hub customization? What sorts of things need to be set up > specially for the root hub device? Offhand I don't see anything in struct > usb_device that could be customized.
Various quirks related to root hubs. For example there's the AMD756 issue with OHCI (must disable autosuspend, controlled by the driver model wakeup flag on the root hub device), and other chips have had similar problems. I can't do the natural fix for that AMD756 quirk as part of one-time setup because accessing the root hub causes oopsing. > Speaking of refactoring, the hcd->start and ->stop routines are also a bit > strange. For example, the start method in uhci-hcd.c does a lot of the > work that should be done in an init method, and it duplicates some of the > work done by resume. Yeah, I just noticed that. That's more of a UHCI issue. Conceptually, the init()/setup()/reset() routine should handle all the one-time init, so start() can fire as needed ... even in the lost-power resume() scenarios. The non-PCI HCDs don't currently call init/setup/restart since they mostly have normal-ish probe() logic. There's still some startup code that's not shared (and could be) but a lot of that is just a legacy of the 2.2 OHCI codebase and its curious calling conventions. > Maybe it would make more sense to have the method formerly known as > "reset" prepare almost everything, leaving the hardware essentially in > bus-suspend state. I'd say "bus off", actually. There are some devices that can't enumerate properly unless they get a full VBUS power cycle, and switching power off during USB startup is a big help. (I'm thinking of a particular MGS UPS, oddly enough.) That in fact is what the OHCI and EHCI init/setup/reset routine should be doing now. > Then instead of calling start, we could just call > bus_resume. Likewise, for remove processing we would call bus_suspend > followed by a new "destroy" method. Sounds like a good approach to me. There's some confusion about just what stop() does ... currently it includes some of what I'd expect that destroy() to handle. How would that work for the resume-after-poweroff scenario though? It'd be nice if that were basically the same HCD startup sequence. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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
