From: Phillip Susi <psusi@cfl.rr.com>
To: Olivier Galibert <galibert@pobox.com>, linux-kernel@vger.kernel.org
Subject: Re: Flames over -- Re: Which is simpler?
Date: Mon, 20 Feb 2006 13:20:23 -0500 [thread overview]
Message-ID: <43FA0867.5060001@cfl.rr.com> (raw)
In-Reply-To: <20060220165153.GA33155@dspnet.fr.eu.org>
Olivier Galibert wrote:
> USB has this additional problem that devices lose their addresses when
> the power is removed (it's very agressively hotplug). So you can have
> the devices moving around under your feet between poweroff and poweron
> just because the devices happened to have enumerated in a different
> order at boot time.
>
Isn't that address abstracted out by the usb layer? i.e. there is no
relationship between the device number and the usb bus address, so
there's no reason the usb layer can't update it's internal data
structures to point the old device to the new bus address. Also if the
USB host controller wants to, can't it assign any address it likes to
each device on the bus? It doesn't HAVE to assign them in sequence as
the devices are enumerated does it?
I'm not all that familiar with USB, but I'd imagine it is somewhat like
I2C/SMBUS: each device has a descriptor block that contains information
about itself. This is going to be unique for any given device. The
host controller begins by querying the broadcast address, and all
unconfigured devices respond. At some point a bit in their descriptor
blocks will differ, and there will be a collision, at which point, the
device trying to transmit a high bit will yield and let the others
continue. Eventually only one device will be left having sent its
entire descriptor block to the host, and the host can then assign a
unique address to that device. The host repeats this until all devices
have been assigned an address.
Because of this, given the same hardware on the bus, the same
enumeration will happen every time, and the host can assign whatever
address it wants to each device should it choose to do so rather than
just assign them in ascending order. If the host wanted to, it could
power down the bus, and when it powers back up, it could assign the same
addresses that they had before to the devices as they are enumerated,
and new devices would get unused addresses.
next prev parent reply other threads:[~2006-02-20 18:21 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-13 19:16 Flames over -- Re: Which is simpler? David Brownell
2006-02-13 20:08 ` Phillip Susi
2006-02-14 3:10 ` David Brownell
2006-02-14 6:05 ` Phillip Susi
2006-02-14 17:04 ` David Brownell
2006-02-15 23:43 ` Pavel Machek
2006-02-18 20:51 ` David Brownell
2006-02-19 6:06 ` Phillip Susi
2006-02-20 5:50 ` David Brownell
2006-02-20 16:07 ` Phillip Susi
2006-02-20 16:51 ` Olivier Galibert
2006-02-20 18:20 ` Phillip Susi [this message]
2006-02-20 18:44 ` Olivier Galibert
2006-02-20 21:45 ` Phillip Susi
2006-02-21 16:19 ` David Brownell
2006-02-21 18:30 ` Phillip Susi
-- strict thread matches above, loose matches on Subject: below --
2006-02-12 16:57 Alan Stern
2006-02-13 0:51 ` Phillip Susi
2006-02-13 2:19 ` Alan Stern
2006-02-13 3:52 ` Phillip Susi
2006-02-13 5:43 ` Kyle Moffett
2006-02-13 16:40 ` Phillip Susi
2006-02-13 16:31 ` Alan Stern
2006-02-13 17:14 ` Phillip Susi
2006-02-13 20:04 ` Alan Stern
2006-02-13 20:38 ` Phillip Susi
2006-02-13 21:24 ` Alan Stern
2006-02-13 22:27 ` Rafael J. Wysocki
2006-02-14 19:26 ` Alan Stern
2006-02-14 20:41 ` Rafael J. Wysocki
2006-02-14 21:08 ` Lee Revell
2006-02-15 15:56 ` Alan Stern
2006-02-13 22:51 ` J. Bruce Fields
2006-02-13 23:47 ` Phillip Susi
2006-02-14 0:50 ` Kyle Moffett
2006-02-14 2:09 ` Phillip Susi
2006-02-14 4:09 ` Kyle Moffett
2006-02-14 4:28 ` Alan Stern
2006-02-14 5:11 ` Kyle Moffett
2006-02-14 15:33 ` Alan Stern
2006-02-14 6:27 ` Phillip Susi
2006-02-14 16:23 ` Kyle Moffett
2006-02-14 18:39 ` Phillip Susi
2006-02-14 19:55 ` Kyle Moffett
2006-02-14 21:13 ` Phillip Susi
2006-02-14 23:32 ` Kyle Moffett
2006-02-15 3:08 ` Phillip Susi
2006-02-14 19:14 ` Olivier Galibert
2006-02-14 19:37 ` Phillip Susi
2006-02-17 21:04 ` Pavel Machek
2006-02-18 16:34 ` Phillip Susi
2006-02-18 17:29 ` Pavel Machek
2006-02-19 5:52 ` Phillip Susi
2006-02-19 9:02 ` Pavel Machek
2006-02-19 16:35 ` Phillip Susi
2006-02-19 16:41 ` Alan Stern
2006-02-19 19:17 ` Phillip Susi
2006-02-19 19:43 ` Pavel Machek
2006-02-20 0:56 ` Olivier Galibert
2006-02-20 1:01 ` Pavel Machek
2006-02-20 1:26 ` Olivier Galibert
2006-02-20 4:04 ` Alan Stern
2006-02-19 20:16 ` Bernd Eckenfels
2006-02-18 21:04 ` Alan Stern
2006-02-19 0:02 ` Andrew Morton
2006-02-19 6:02 ` Phillip Susi
2006-02-19 6:32 ` Andrew Morton
2006-02-19 16:39 ` Phillip Susi
2006-02-19 16:54 ` Alan Stern
2006-02-19 20:02 ` Andrew Morton
2006-02-19 20:44 ` Oliver Neukum
2006-02-19 21:02 ` Andrew Morton
2006-02-20 6:55 ` Oliver Neukum
2006-02-20 7:29 ` Andrew Morton
2006-02-20 7:57 ` Andrew Morton
2006-02-14 14:15 ` hackmiester / Hunter Fuller
2006-02-15 23:51 ` Pavel Machek
2006-02-13 2:25 ` Kyle Moffett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43FA0867.5060001@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=galibert@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox