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
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:23 EST