"default address": per root hub/host controller or per hub ?

[erdmann]

I am working on a USB driver and have the following question:

the USB spec defines a "default address" that you can use to communicate with a device that has not yet been assigned a valid device address.
However the USB spec is unclear if a "default address" needs to be managed per host controller or per hub.

Consider this: you have a host controller / root hub with 4 ports. You plug in 3 ordinary devices in 3 of the ports. In the forth port, you plug in an external hub that has for example 7 ports.
Question: is there only 1 "default address" shared among 10 ports (3 ports from the root hub plus the 7 ports from the external hub) or are there 2 "default addresses" to manage: 1 for the 3 devices attached to the root hub and 1 for the 7 devices attached to the external hub ?


Any help greatly appreciated.

[Bret]

The "default address" is address 0, and is the address a device assumes immediately after it is enabled.  It will respond to all requests to address 0 until its address is changed to a "real" address or it is disabled.

Each device on the bus must have a unique address.  Therefore, only one device at a time on the entire bus can have (respond to) address 0.

Keep in mind that any device downstream of a hub can't respond to address 0 until after the hub itself is enabled, addressed, configured, and the appropriate hub port is enabled.  This applies to the root hub as well as "regular" hubs, except that the root hub doesn't have an address.

[erdmann]

Many thanks for your answer.

Just for confirmation (I am not the long time USB expert):
so (for the given example), if the external hub is enabled+addressed+configured then ALL devices attached as "leaves" to this "tree" consisting of root hub and external hub will respond to one and only one "default address" (whatever logic the USB HW implements to pick/favor only one device at a time to respond to the "default address") ?

[Jan Axelson]

Yes, but a device responds to the default address only after its hub resets the device at the host's request.

Hubs inform the host controller of newly attached devices. The host can communicate with a new device only after the device's hub resets the device.

The host requests to reset one port at a time. After reset, the host communicates with the device first using the default address, then assigning an address and freeing the default address for another port.

[Barry Twycross]

One Important thing is a hub's ports are disabled until the port is reset. When a device is attached, its port is disabled, so no traffic flows to the device. When the port/device is reset, the reset not only tells the device to assume the default address, but the hub port to become enabled.

The host has to arrange to only ever have one device at the default address on an enabled port at one time. All traffic is broadcast to all devices, so if more than one device ever becomes enabled on an enabled port at the default address, everything falls apart. I've had it happen occasionally, enumeration may become impossible at that point. My implementation used a mutex lock and a queue to make sure only one device was at address zero at once.

If you have mutiple busses, ie each bus has a separate host controller, each bus can have its own independent device zero. Traffic is not broadcast across busses, only to all devices on a bus.

[Jan Axelson]

Good point about multiple busses, which most PCs have these days.

[Bret]

FWIW, I was purposely using the term Enable instead of Reset, because with USB 1 host controllers and hubs they are not the same thing.

In a UHCI host controller (not sure about OHCI), resetting and enabling are two separate and distinct procedures -- you can do one without doing the other.  In a USB 1 hub, the port is automatically Enabled at the end of a Reset, but you can also Enable the port without Resetting it.

That all changed with USB 2 and EHCI, where the terms Reset and Enable can pretty much be used interchangeably.

[Barry Twycross]

It changed with USB 1.1. The USB 1.1 spec cleared up a lot of the problems with 1.0, one of those was allowing a port to be enabled only by a reset.

I never realised a set_port_feature(PORT_ENABLE) was allowed, I started implementing to draft 1.1 specs. I know some older hubs would respond to a set enable, I never realised it was explicitly allowed.

[Bret]

I actually did some experimentation with it when I first started out, and every v1 hub I tested accepted the Enable request.  I think every device I tried at the time would also work correctly by just being Enabled without actually needing a full Reset (that was a long time ago, though).  I also played around some with simply Enabling and Disabling devices (no Resets involved at all) and things always seemed to work just fine.  I know that's not really acceptable any more, and newer devices would probably be less likely than older devices to work that way, so I haven't tried it lately.  I still have a few USB 1 hubs laying around, which come in very handy sometimes.

[erdmann]

Many thanks for the answers. I now finally understood that it is the job of the driver SW to make sure that only exactly one port is reset and therefore addressable via the default address at any point in time. That was the missing bit.
In the past I thought that the USB HW would somehow handle "assignment of default address to exactly one device" ("first come, first serve" or whatever other way).