> [EMAIL PROTECTED] said:
> > Yes, your proposal is to init only "usbcore" from init/main.c. I
> > still don't see a need to do this in test10. It's fixed now AFAIK.
>
> Not my proposal. The proposal to which Russell was objecting.
>
> My proposal was to just make the thing work without having
[EMAIL PROTECTED] said:
> Yes, your proposal is to init only "usbcore" from init/main.c. I
> still don't see a need to do this in test10. It's fixed now AFAIK.
Not my proposal. The proposal to which Russell was objecting.
My proposal was to just make the thing work without having to care abou
> From: Russell King [mailto:[EMAIL PROTECTED]]
>
> Dunlap, Randy writes:
> > I'm not following your argument very well. I've read it
> > and reread it several times.
> > Does adding a call to usb_init() in init/main.c cause
> > USB to be init 2 times?
>
> No. As I said elsewhere in this threa
[EMAIL PROTECTED] said:
> No. As I said elsewhere in this thread, the USB OHCI chip is not
> accessible until other board-specific initialisation has happened.
> This is done via an initcall. Unfortunately, moving usb_init() back
> into init/main.c will mean that USB is again initialised befor
Dunlap, Randy writes:
> I'm not following your argument very well. I've read it
> and reread it several times.
> Does adding a call to usb_init() in init/main.c cause
> USB to be init 2 times?
No. As I said elsewhere in this thread, the USB OHCI chip is not accessible
until other board-specific
Randy.Dunlap wrote:
> > While Jeff and I basically agree on the short-term
> > solution (if one is still needed, altho I'm not aware of
> > any init order problems in USB in 2.4.0-test10), my
> > recollection of Linus's preference (without
> > looking it up) is to remove the calls from init/main.c
Dunlap, Randy writes:
> While Jeff and I basically agree on the short-term
> solution (if one is still needed, altho I'm not aware of
> any init order problems in USB in 2.4.0-test10), my
> recollection of Linus's preference (without
> looking it up) is to remove the calls from init/main.c
> and t
s.
~Randy
> -Original Message-
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 04, 2000 12:25 AM
> To: Russell King
> Cc: Dunlap, Randy; 'David Woodhouse'; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: USB init order
Jeff Garzik writes:
> Putting a call into init/main.c isn't a long term solution, but it
> should get us there for 2.4.x... init/main.c is also the best solution
> for ugly cross-directory link order dependencies. I would say the link
> order of foo.o's in linux/Makefile is the most delicate/fra
Russell King wrote:
> There'll be quite a few extra init calls going in there then, with lots
> and lots of ifdefs ;(
I was talking about one or two init/main.c additions. If you know of
"quite a few" link order problems outside of main USB subsystem init,
speak up...
Jeff
--
Jeff Ga
Russell King wrote:
>
> Dunlap, Randy writes:
> > David is entitled to his opinion (IMO).
> > And I dislike this patch, as he and I have already discussed.
> >
> > Short of fixing the link order, I like Jeff's suggestion
> > better (if it actually works, that is): go back to the
> > way it was a
Dunlap, Randy writes:
> David is entitled to his opinion (IMO).
> And I dislike this patch, as he and I have already discussed.
>
> Short of fixing the link order, I like Jeff's suggestion
> better (if it actually works, that is): go back to the
> way it was a few months ago by calling usb_init(
> Personally, I think this fix is less ugly than any of the
> alternatives I've seen so far.
>
> It removes the dependency on init order completely, by
> statically putting
> the hub driver into the usb_driver_list at compile time.
>
> Leave the link ordering stuff for 2.5.
David is entitled
Personally, I think this fix is less ugly than any of the alternatives I've
seen so far.
It removes the dependency on init order completely, by statically putting
the hub driver into the usb_driver_list at compile time.
Leave the link ordering stuff for 2.5.
Index: drivers/usb//hub.c
14 matches
Mail list logo
