[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 09/14/2015 12:36 PM, George Dunlap wrote:
On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
On 09/11/2015 04:41 PM, Ian Campbell wrote:

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.


No. Each hub is just a port which happens to have more ports behind it.

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


Correct.

HUB1==BUS2


No, Just Bus1-Port0 or Bus1:Devnum1

HUB2==BUS2


Bus1-Port1 or Bus1:Devnum2

HUB3==BUS4


Bus1-Port1.Port1 or Bus1:Devnum3

ROOT1==BUS42


Bus2

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]


Device D: Bus1-Port1.Port1.Port0 or e.g. Bus1:Devnum4
Device A: Bus1-Port0.Port0 or e.g. Bus1:Devnum5

Is that right?

One bus can have up to 31 ports.


So the answer is that hostaddr can be 5 bits?


5*8 (7 hubs and a device at the last level) == 40, that's the 1 trillion
I suggested before. Things are a little bit more complicated. A devnum
in a bus is never assigned twice. So when you plug in a device, it might
get devnum 6. Unplug it and replug it again will lead to devnum 7.

   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.


Busnum can grow to arbitrary values. A new USB bus detected will get a
new bus number. Removing it and adding it again will again use a new
number.

FWIW libusb seems to define these as uint8:

http://libusb.org/static/api-1.0/group__dev.html#gaf2718609d50c8ded2704e4051b3d2925

(I *think* that "bus number" and "device address" correspond to busnum
and devnum...)

Anyone want to look into the Linux source code to find out how big it
will allow busnum / devnum to grow?

drivers/usb/core/hcd.c is using a bitmap to find the next bus number
currently not in use. It's size is USB_MAXBUS which in turn has the
value 64.

choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
device numbers. Here the highest number supported is 127.


Juergen

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.