From: Ian Campbell <ian.campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>, Chun Yan Liu <cyliu@suse.com>,
xen-devel@lists.xen.org
Cc: george.dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com,
Jim Fehlig <JFEHLIG@suse.com>, Simon Cao <caobosimon@gmail.com>,
wei.liu2@citrix.com
Subject: Re: [PATCH V6 3/7] libxl: add pvusb API
Date: Fri, 11 Sep 2015 15:41:44 +0100 [thread overview]
Message-ID: <1441982504.3549.69.camel@citrix.com> (raw)
In-Reply-To: <55F2E29D.10805@suse.com>
On Fri, 2015-09-11 at 16:18 +0200, Juergen Gross wrote:
> On 09/11/2015 04:09 PM, Ian Campbell wrote:
> > On Fri, 2015-09-11 at 15:55 +0200, Juergen Gross wrote:
> > > On 09/11/2015 03:26 PM, Ian Campbell wrote:
> > > > On Thu, 2015-09-10 at 23:42 -0600, Chun Yan Liu wrote:
> > > > >
> > > > > > Do these fields have any particular size requirements arising
> > > > > > from
> > > > > > e.g. the
> > > > > > USB spec or from possible dom0 implementations?
> > > > > >
> > > > > > If they have a well defined fixed size from a USB spec then
> > > > > > maybe
> > > > > > we
> > > > > > could
> > > > > > use the appropriate fixed size types?
> > > > >
> > > > > Di> dn't see the size limitation. In Linux kernel code, busnum
> > > > > and
> > > > > devnum (here
> > > > > 'hostbus, hostaddr') are both 'int' type.
> > > >
> > > > Is that a Linux-specific implementation detail or a fundamental
> > > > property of
> > > > USB? We should be designing the interface around Linux
> > > > implementation
> > > > details. It seems like something in the USB spec ought to define
> > > > precisely
> > > > the number of bits in both a bus number and a device address within
> > > > that
> > > > bus.
> > >
> > > The USB spec is only about _the_ bus. How many buses a host can
> > > operate and how they are numbered is outside the USB spec.
> > >
> > > Devices are addressed via their ports in the USB protocol. devnum
> > > is a unique index for a device on the bus, the USB protocol
> > > equivalent
> > > is a list of ports of:
> > > - 1 member in case of direct attached devices
> > > - multiple members in case of hubs between bus and device
> >
> > Thanks for the info. So an "address" in the USB protocol is actually a
> > "path" and "hostbus" is an implementation dependent shorthand for all
> > but
> > the last link in that path.
>
> I'm not sure in which direction you are looking. "address" is a path.
> A path is normally a list of ports starting at the host and walking
> through all hubs until you reach the device. The "bus" is the root
> of that path. So the number of buses the host knows of is the number
> of USB host adapters without any hub.
OK, I thought I understood but the above suggests not.
In USB speak, the address is a list of port numbers, which you follow from
the host bus which is the root.
In Linux speak a "bus" is actually each hub along that path.
Let me try a worked example and see if I've got it right. Lets take this
topology:
ROOT0
|-PORT0 ----+--HUB1
|-PORT1-, |-PORT0 -- DEVICE A
| `-PORT1 -- DEVICE B
|
`--HUB2
|-PORT0 -- DEVICE C
`-PORT1 -- HUB3
|-PORT0 -- DEVICE D
`-PORT1 -x
ROOT1 -- ... other stuff
In the USB protocol there are two buses corresponding to ROOT0 and ROOT1.
So in the protocol the address of DEVICE D on the bus associated with ROOT0
is [1,1,0], that is PORT1 on ROOT0 => PORT1 on HUB2 => PORT0 on HUB3.
DEVICE A is [0,0] on the bus associated with ROOT0, similarly.
In the Linux numbering scheme each ROOTn or HUBn is given a bus number,
somewhat arbitrarily (although I'm sure there is a scheme by which they
allocated). So perhaps:
ROOT0==BUS1
HUB1==BUS2
HUB2==BUS2
HUB3==BUS4
ROOT1==BUS42
And in this scheme the address is hostbus+hostaddr, so DEVICE D is [3,0],
that is hostbus==3==HUB3, and port 0. And DEVICE A is [2,0]
Is that right?
> One bus can have up to 31 ports.
So the answer is that hostaddr can be 5 bits?
> In theory I think up to 7 cascaded
> hubs are possible, but I don't think the resulting theoretical maximum
> of about 1 trillion devices on a bus is to be considered. :-)
And this suggests that in principal a Linux hostbus could be 5*7 bits == 35
bits, maybe. Or at least that any USB address can be encoded in that many
bits.
Ian.
next prev parent reply other threads:[~2015-09-11 14:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-10 10:35 [PATCH V6 0/7] xen pvusb toolstack work Chunyan Liu
2015-08-10 10:35 ` [PATCH V6 1/7] libxl: export some functions for pvusb use Chunyan Liu
2015-08-11 11:26 ` Wei Liu
2015-08-10 10:35 ` [PATCH V6 2/7] libxl_read_file_contents: add new entry to read sysfs file Chunyan Liu
2015-08-11 11:26 ` Wei Liu
2015-08-12 2:37 ` Chun Yan Liu
2015-08-13 9:11 ` Wei Liu
2015-08-10 10:35 ` [PATCH V6 3/7] libxl: add pvusb API Chunyan Liu
2015-08-11 11:27 ` Wei Liu
2015-08-12 2:24 ` Chun Yan Liu
2015-08-13 9:09 ` Wei Liu
2015-08-14 1:49 ` Chun Yan Liu
2015-08-18 2:31 ` Chun Yan Liu
2015-08-31 6:10 ` Chun Yan Liu
2015-09-08 14:17 ` Ian Campbell
2015-09-08 16:52 ` George Dunlap
2015-09-09 7:38 ` Chun Yan Liu
2015-09-17 8:19 ` Chun Yan Liu
2015-09-17 9:54 ` George Dunlap
2015-09-29 17:19 ` Wei Liu
2015-09-17 8:20 ` Chun Yan Liu
2015-09-11 5:42 ` Chun Yan Liu
2015-09-11 13:26 ` Ian Campbell
2015-09-11 13:55 ` Juergen Gross
2015-09-11 14:09 ` Ian Campbell
2015-09-11 14:18 ` Juergen Gross
2015-09-11 14:41 ` Ian Campbell [this message]
2015-09-11 15:42 ` Ian Jackson
2015-09-14 3:48 ` Juergen Gross
2015-09-14 10:36 ` George Dunlap
2015-09-14 10:53 ` Juergen Gross
2015-09-14 11:12 ` Ian Jackson
2015-09-14 11:23 ` Juergen Gross
2015-09-14 14:03 ` George Dunlap
2015-09-17 8:24 ` Chun Yan Liu
2015-09-15 8:14 ` Chun Yan Liu
2015-08-10 10:35 ` [PATCH V6 4/7] libxl: add libxl_device_usb_assignable_list API Chunyan Liu
2015-08-10 10:35 ` [PATCH V6 5/7] xl: add pvusb commands Chunyan Liu
2015-08-10 10:35 ` [PATCH V6 6/7] xl: add usb-assignable-list command Chunyan Liu
2015-08-10 10:35 ` [PATCH V6 7/7] domcreate: support pvusb in configuration file Chunyan Liu
2015-08-11 11:27 ` Wei Liu
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=1441982504.3549.69.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JFEHLIG@suse.com \
--cc=caobosimon@gmail.com \
--cc=cyliu@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=jgross@suse.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.