[U-Boot] Multiple device support -- sorry state :(

[ksi at koi8.net]

OK, this is _NOT_ just multiple I2C adapters... The entire thing is
fundamentally broken.

One supposed to have _THE_ device and only this device is somehow supported.

Now it is USB. Each and every USB driver exports the same set of functions,
submit_XXX_msg(...) That means there can be one and only one USB device in
the system.

Let's take e.g. widely used ISP1563 PCI USB controller. It has _TWO_ OHCI
controllers. Existing usb_ohci.c code only supports one. That means that one
can only use odd numbered ports (1 and 3) for any USB devices. Ports 2 and 4
are not usable at all. Not just together with odd numbered ones but even
_INSTEAD_ of those.

But wait, there is more... This very same controller also has a 4-port EHCI
controller for USB 2.0 support. This is not supported at all because
usb_ehci_pci.c is a mere stub that does NOT support _ANY_ PCI EHCI
controller. But it would not do any good if it did support ISP1563 -- there
should be one and only one USB controller, _THE_ USB controller... EHCI
driver, usb_ehci_core.c exports exactly the same submit_XXX_msg() set of
function so it can _NOT_ coexist with anything else.

So what's the choice? Let's say we somehow made that usb_ehci_pci.c stub in
a real driver and got ISP1563 (or _ANY_ other USB2.0 PCI adapter) recognized
and initialized. This hypothetically gives us all 4 ports because all 4 are
supported by EHCI vs. only 2 by OHCI. Would it do any good? The answer is
_NO_.

EHCI does _NOT_ support slower USB1.X ports so one can _NOT_ hook his e.g.
USB keyboard to EHCI controller. It is only for hi-speed devices. USB2.0
controller actually consists of an EHCI and set of slower USB1.X controllers
that share the same USB pins. If a connected device supports high speed,
EHCI is used. If it does NOT support high speed, driver should made EHCI
controller to give up ownership of that particular USB port to OHCI (or
whatever it is) and pass control to OHCI driver. That is how USB works.

Now we suddenly have _THREE_ USB controllers while our software only
supports one. And that is _NOT_ some exotic situation with multiple chips or
other strange design -- e.g. MPC8548 does NOT have a built-in USB controller
so I added a single PCI chip to provide for a USB interface.

One can recommend using only the first OHCI controller in U-Boot somehow
tolerating it being painfully slow with storage devices etc. and limited
with what ports can be used but that is also _NOT_ a solution... OHCI only
allows for 2 ports and in our case they are both already used (KBD + MOUSE.)
Sure we don't need a mouse in U-Boot but we _DO_ need it to be connected
anyways because we boot full-blown Fedora with X that uses mouse. That means
we do NOT have any USB ports available for storage or anything else...

USB keyboard is another grand kludge deserving its own chapter... As of now
one can only switch to it from command line because USB is not even
initialized until do_usb() from cmd_usb.c is called... What if we do NOT
have a serial console at all?

Grrr...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************