usb_subr.c usbdi.h usb_port.h

[Joerg Anslik]

Yeah,

>   could you post a  short explanation as to the meaning of USB_START_ADDR ?

"USB_START_ADDR" is used in usbd_probe_and_attach(), the function
which is called first by the underlying USB [hub] driver stuff on
recognizing a new probed USB device.

Devices like "ums", "umass" or whatever are recognized and initialized
as soon as they are plugged in (or have already been plugged in on
system startup), since the "firmware" they need to function is already
part of their respective drivers (to tell the truth, they don't have
any "firmware" at all, but basic USB data transport mechansims.
"umass", e.g, behaves like any other IDE/SATA HD -- it's just the
so-called "USB endpoints" (basic I/O functions, that is), which cause
the device to behave like a "normal" IDE/SATA disk. It's all
transparent to userland: USB HDs show up like "normal" disks; you or
the system doesn't have to bother with magical USB stuff...it's all
provided by the respective driver.

USB WLAN interfaces, however, are special:

Chipsets like the Intersil 3886xx (Prism Javelin), which I'm currently
fighting with, just provide the same basic USB behaviour on startup,
that is, ehci says "are you there?" and the WLAN chip responds: "yes!"

That's okay for a HD, but for a WLAN device to work, it needs a little
more knowledge about its capabilities, registers and data input/output
storage locations and what USB endpoint causes what action.
("Endpoint", in USB speech, is the device itself (the endpoint of the
USB connection), but also defines read or write operations to perform
certain actions, like getting the MAC address or common device status
(up/down/idle/busy/whatever).

This knowledge, ot let's call it "intelligence", is provided by the
chipsets' firmware, which needs to be downloaded once the device has
been successfully probed/attached. And here's the problem: a USB
device that has already been probed and attached is considered
"online" or "attached", and so the OS thinks it's okay to read/write
data to/from its corresponding endpoints.

With WLAN equipment, we'd end up somewhere in the middle of nowhere,
since the chipset is aware of its very own existence, but it doesn't
know what action to perform on a, let's say, 0x33, 0x01 endpoint
request. (For the ISL3886xx, this means "download external firmware".)

To get the missing link, all WLAN chipsets have a volatile memory
area, big enough to hold their "intelligence", which is, you already
guessed it, the firmware.

So, to get out of the "device-has-been-probed-and-attached" and the
"but-the-device-doesn't-know-what-to-do", there has to be a way of
telling the device "what-to-do-if...".

And this is where "USB_START_ADDR" finally comes in: setting the start
address to "0" (which is what USB_START_ADDR is defined to) and
deleting the corresponding, already probed startup device, the system
ends up with a known, but stupid device somehow, returning
"USBD_NORMAL_COMPLETION" at the end of probing a "UHUB_UNK_INTERFACE".

To cut a long story short: a start address offset of "0" means "not
yet completely initialized". I'll leave out the very details here,
since I can already hear you snorring.

All of this is nomally done during the call to the USB_ATTACH
function, causing the driver (WLAN) to execute
"download_whatever_firmware". Assuming a successful completion (a
valid firmware file, that is), we then end up with a device which has
just experienced a fresh warm reset following a firmware download.

Et voilà: the device is aware of itself (at least should be :), with
everything at hand it always wanted to know about its USB endpoints,
registers, etc. and how to handle them, but was afraid to ask.

And if all goes well during boot, you finally should see something
like

login:


--j



-----------------------------------------------------
who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount;
fsck; more; yes; gasp; umount; make clean; sleep