Messages in this thread |  | | Date | Fri, 27 Oct 2000 20:57:03 -0700 | From | Greg KH <> | Subject | Re: test[9-10] USB depmod unresolved symbols |
| |
Thanks Keith for that detailed description of what is going wrong, I would have never figured that out.
On Sat, Oct 28, 2000 at 12:29:39PM +1100, Keith Owens wrote: > > I will add LINK_FIRST and LINK_LAST to kbuild this weekend and > reinstate the missing lines in drivers/usb/Makefile. What I need from > the USB group is a documented (i.e. *why* is this order required) > definition of what needs to be linked first into usbdrv.o, and somebody > we can query if there are problems in the future. It will probably be > as simple as
Yeah, a valid reason for LINK_FIRST and LINK_LAST!
I'll try my hand at the wording. Randy, does this look acceptable:
# usb.o contains __init usb_init which must be executed before all # other usb __init routines, the remaining usb __init routines can be # executed in any order. Execution order of __init routines depends # on link order so usb.o must be linked first. Otherwise, the # individual drivers will be initialized before the hub driver is, # causing the hub driver initialization sequence to needlessly probe # every USB driver with the root hub device. This causes a lot of # unnecessary system log messages, a lot of user confusion, and has # been known to cause a incorrectly programmed USB device driver to # grab the root hub device improperly. # Greg Kroah-Hartman, 27 Oct 2000
LINK_FIRST := usb.o
> but you know better than I what the required order will be and why. > Are there any other link order problems in USB?
That's the only known link problem for the USB drivers.
Thanks,
greg k-h
-- greg@(kroah|wirex).com http://immunix.org/~greg [unhandled content-type:application/pgp-signature] |  |