Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel