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
===================================================================
RCS file: /inst/cvs/linux/drivers/usb/hub.c,v
retrieving revision 1.2.2.38
diff -u -r1.2.2.38 hub.c
--- drivers/usb//hub.c 2000/10/12 16:50:36 1.2.2.38
+++ drivers/usb//hub.c 2000/10/31 17:50:58
@@ -759,11 +759,13 @@
return 0;
}
-static struct usb_driver hub_driver = {
+struct usb_driver hub_driver = {
name: "hub",
probe: hub_probe,
ioctl: hub_ioctl,
- disconnect: hub_disconnect
+ disconnect: hub_disconnect,
+ serialize: __MUTEX_INITIALIZER(hub_driver.serialize),
+ driver_list: LIST_HEAD_INIT(usb_driver_list)
};
/*
@@ -772,11 +774,6 @@
int usb_hub_init(void)
{
int pid;
-
- if (usb_register(&hub_driver) < 0) {
- err("Unable to register USB hub driver");
- return -1;
- }
pid = kernel_thread(usb_hub_thread, NULL,
CLONE_FS | CLONE_FILES | CLONE_SIGHAND);
Index: drivers/usb//usb.c
===================================================================
RCS file: /inst/cvs/linux/drivers/usb/usb.c,v
retrieving revision 1.2.2.52
diff -u -r1.2.2.52 usb.c
--- drivers/usb//usb.c 2000/10/04 12:29:27 1.2.2.52
+++ drivers/usb//usb.c 2000/10/31 17:50:58
@@ -56,8 +56,14 @@
/*
* We have a per-interface "registered driver" list.
+ * We link the USB hub driver into the list statically at compile
+ * time, to prevent ugly dependencies on the order in which the
+ * init routines are called.
*/
-LIST_HEAD(usb_driver_list);
+
+extern struct usb_driver hub_driver;
+
+struct list_head usb_driver_list = LIST_HEAD_INIT(hub_driver.driver_list);
LIST_HEAD(usb_bus_list);
static struct usb_busmap busmap;
--
dwmw2
> 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 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()
from init/main.c and making the module_init(usb_init);
in usb.c conditional (#ifdef MODULE).
~Randy
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()
> from init/main.c and making the module_init(usb_init);
> in usb.c conditional (#ifdef MODULE).
However, that breaks the OHCI driver on ARM. Unless we're going to start
putting init calls back into init/main.c so that we can guarantee the order
of init calls which Linus will not like, you will end up with a lot of ARM
guys complaining.
Linus, your opinion would be helpful at this point.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
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 few months ago by calling usb_init()
> > from init/main.c and making the module_init(usb_init);
> > in usb.c conditional (#ifdef MODULE).
>
> However, that breaks the OHCI driver on ARM. Unless we're going to start
> putting init calls back into init/main.c so that we can guarantee the order
> of init calls which Linus will not like, you will end up with a lot of ARM
> guys complaining.
>
> Linus, your opinion would be helpful at this point.
Back when some of the initial USB initcall stuff started appearing,
there were similar discussions, similar problems, and similar
solutions. I was also wondering how fbdev (which needs to give you a
console ASAP) would work with initcalls, etc. At the time (~6 months
ago?), Linus' opinion was basically "if the link order hacking starts to
get ugly, just put it in init/main.c" So, Randy really should be
calling the quoted text above "Linus' suggestion" ;-)
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/fragile of all
the Makefiles... touching linux/Makefile link order this close to 2.4.0
is asking for trouble. Compared to that, adding a few lines to
init/main.c isn't so bad.
IMHO,
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
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 Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
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/fragile of all
> the Makefiles... touching linux/Makefile link order this close to 2.4.0
> is asking for trouble. Compared to that, adding a few lines to
> init/main.c isn't so bad.
There'll be quite a few extra init calls going in there then, with lots
and lots of ifdefs ;(
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
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 to use __initcalls.
~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 dependencies.
>
>
> 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 few months ago by calling usb_init()
> > > from init/main.c and making the module_init(usb_init);
> > > in usb.c conditional (#ifdef MODULE).
> >
> > However, that breaks the OHCI driver on ARM. Unless we're
> going to start
> > putting init calls back into init/main.c so that we can
> guarantee the order
> > of init calls which Linus will not like, you will end up
> with a lot of ARM
> > guys complaining.
> >
> > Linus, your opinion would be helpful at this point.
>
> Back when some of the initial USB initcall stuff started appearing,
> there were similar discussions, similar problems, and similar
> solutions. I was also wondering how fbdev (which needs to give you a
> console ASAP) would work with initcalls, etc. At the time (~6 months
> ago?), Linus' opinion was basically "if the link order
> hacking starts to
> get ugly, just put it in init/main.c" So, Randy really should be
> calling the quoted text above "Linus' suggestion" ;-)
>
> 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/fragile of all
> the Makefiles... touching linux/Makefile link order this
> close to 2.4.0
> is asking for trouble. Compared to that, adding a few lines to
> init/main.c isn't so bad.
>
> IMHO,
>
> Jeff
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 to use __initcalls.
The problem for ARM is that Linux does a lot of the initialisation for
some machines, which basically means the hardware isn't setup for access
to the USB device if the USB initialisation was placed in init/main.c
(this initialisation is done by the very first initcall on ARM). However,
that said, we may be able to get away with only adding hw_sa1100_init()
before the USB call, but this is only one family of the ARM machine types.
BTW, I've long lost track of what the original problem that sparked off
this thread was, does someone have a quick reference to it? (please
reply in private mail). Thanks.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
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
> > and to use __initcalls.
>
Russell King wrote:
> The problem for ARM is that Linux does a lot of the initialisation for
> some machines,
but not for ARM ?
> which basically means the hardware isn't setup
> for access
> to the USB device if the USB initialisation was placed in init/main.c
> (this initialisation is done by the very first initcall on
> ARM). However,
> that said, we may be able to get away with only adding
> hw_sa1100_init()
> before the USB call, but this is only one family of the ARM
> machine types.
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?
I'm not complaining or arguing against you, just
trying to understand better.
> BTW, I've long lost track of what the original problem that
> sparked off
> this thread was, does someone have a quick reference to it? (please
> reply in private mail). Thanks.
There were several threads but I can't find the
"original" one right now. IIRC, it was simply that
CONFIG_USB=y and CONFIG_USB_*=m (any USB except usbcore
built as modules) caused depmod problems, but that could
be incorrect also.
~Randy
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 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 before any initcalls, which means for these
boards USB will be non-functional without additional changes over and above
just moving usb_init().
I hope this helps you understand the problem.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
[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 before any
> initcalls, which means for these boards USB will be non-functional
> without additional changes over and above just moving usb_init().
But OHCI init isn't called from usb_init() is it?
The proposal is only to move the single call to usb_init() back into
init/main.c - not to move all the USB initcalls back.
--
dwmw2
> 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 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 before any initcalls, which
> means for these
> boards USB will be non-functional without additional changes
> over and above just moving usb_init().
>
> I hope this helps you understand the problem.
Yes, that does help.
David Woodhouse wrote:
> But OHCI init isn't called from usb_init() is it?
No, it's not. It's another __initcall (module_init).
> The proposal is only to move the single call to usb_init() back into
> init/main.c - not to move all the USB initcalls back.
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.
~Randy
[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 about
the link order.
--
dwmw2
> [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 about the link order.
>
> --
> dwmw2
OK, I stand corrected. My bad.
Sounds like we basically all want the same thing. :)
~Randy