On Friday 22 October 2004 10:49, Alan Stern wrote: > David: > > While working on the change to add the USB bus number onto the IRQ action > name, in particular the part to modify the non-PCI host drivers, the > project sort of mutated out of control and turned into a large refactoring > of the HCD initialization code. Although this probably doesn't make any > significant difference to the executable size (maybe enlarges it a > little), it does remove a lot of error-prone redundancy from the source > code. Also the new code tends to be more thorough and does more error > checking than the old code.
It's needed some work ... the HCDs have morphed a lot since that code first started, BIOS interactions became clearer too. > I've only been able to test this with UHCI and EHCI. Maybe you can try it > out with some of the more obscure drivers. I can't even compile them. I can't either, without your patch ... ;) > There are three aspects that I am especially uncertain about: > > The order of acquisition of some resources has been changed, > maybe even rearranged with respect to a device-specific > initialization routine. It doesn't look like it will cause > trouble, but I can't be sure. I think the main rule is that they should all be claimed by the time the driver is asked to do Real Work. > The resource value displayed in the dev_info() in usb_hcd_init2 > is sometimes a pointer and sometimes not. The code casts it > to unsigned long; is this okay? I'd need to see the patch ... the resource values might be good cases to use the iomap() infrastructure. > I don't understand the call to omap_free_gpio(), which appears > in the shutdown path but not the error path in ohci-omap.c. Looks a little quirky, but it's board-specific. The OSK board seems to wire that "General Purpose I/O" pin from the chip for some kind of USB-related output. (Not VBUS switching; that uses a GPIO from the TPS65010 battery management chip, not the OMAP-5912 chip.) It'd be better to claim it in the driver probe() routine, release it in remove(); the claim is just to catch inter-driver confusion. Embedded CPUs usually have a few dozen GPIOs, useful for all kinds of things (including IRQ lines). SouthBridge chips have fewer, and their use is hidden in board-specic BIOS code. In fact, even the net2280 chip has a few GPIOs (wired to LEDs on NetChip's PCI cards). - Dave > Alan Stern > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
