"Dunlap, Randy" wrote:
>
> Hi Miles,
>
> > From: Miles Lane [mailto:[EMAIL PROTECTED]]
> >
> > Okay. It appears I haven't been totally clear in my messages.
> >
> > You are correct that I built usb-ohci as a module in the past.
> > Building usb-ohci in the present as a modules also works
> > (the OHCI bridge gets detected).
>
> You mean the OHCI host controller?
Rats. I need to spend some time learning more about what all the
USB-related terms mean and how they apply in the Linux USB
implementation
Sorry for being confusing.
What I mean is that when I build usb-uhci as a module, boot the
kernel with my Belkin Busport Mobile cardbus card inserted and
then "modprobe usb-ohci", the module loads and I see kernel
messages that indicate the the Belkin Busport Mobile was detected
and its USB ports (it has two) are active. The Busport is specified
to be OHCI compliant.
I *thought* the Belkin Busport Mobile was a USB hub, but it sounds
like I am misusing the term. I *thought* there were UHCI hubs and
OHCI hubs and that they each require different drivers (usb-ohci
or usb-uhci/uhci).
> > I would like the option of building usb-ohci into the kernel
> > and have some usermode process scan for hubs and USB devices
> > after the Yenta and PCMCIA drivers are loaded. Is this what
> > it would take to get the in-kernel usb-ohci driver to perceive
> > the presence of my Belkin cardbus USB hub adapter?
>
> "cardbus USB hub adapter" is confusing to me also.
> Is this a cardbus-to-USB (OHCI host controller) Type II PC Card?
> What's the word "hub" doing here? Are you just referring
> to the "virtual root hub"?
What I mean is that the Belkin Busport Mobile is a cardbus card.
It gives me two USB ports.
> > Note that I am not building the Yenta drive as a module.
> > Perhaps if I tweaked my initialization scripts I could get
> > the Yenta driver to initialize before the USB hubs get
> > scanned. Do you know if this is possible? Perhaps that
> > portion of the initialization sequence is hardcoded in the
> > kernel.
>
> I'm not sure that this can be made to work in the released
> kernel. You may be able to patch a kernel to make it work.
>
> I'm just guessing, but I don't think this is an issue with
> the ordering of some init scripts. I think it's ordering
> within linux/init/main.c, which has the following init
> order (with several omissions here) [// comments are mine]:
>
> pci_init(); // needed early
> usb_init(); // after PCI and before PCMCIA;
> // before do_initcalls() so that
> // USB initcalls work
> do_initcalls();
> ...
> init_pcmcia_ds(); /* Do this last */ // why last?
>
> I don't know why init_pcmcia_ds() should be last.
> For your config & kernel to work the way that you want it
> to (in kernel, not as modules), I would try moving
> init_pcmcia_ds() above usb_init().
> Alternatively, if you aren't using any USB modules,
> you could try moving usb_init() to after init_pcmcia_ds().
Thanks for your patience. I will try this and let you know
if it works. I'll also ask Linus whether there is a compelling
reason to put the PCMCIA/Cardbus initialization toward the
end of the sequence.
Many thanks,
Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
