From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Chun Yan Liu <cyliu@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jim Fehlig <JFEHLIG@suse.com>, Simon Cao <caobosimon@gmail.com>
Subject: Re: [PATCH V6 3/7] libxl: add pvusb API
Date: Mon, 14 Sep 2015 11:36:33 +0100 [thread overview]
Message-ID: <CAFLBxZbWH6LxKxuaTbcnv1rJB8ar4G_WOPfki2YzUc3QqoEszw@mail.gmail.com> (raw)
In-Reply-To: <55F6438A.7090403@suse.com>
On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross <jgross@suse.com> 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?
-George
next prev parent reply other threads:[~2015-09-14 10:36 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
2015-09-11 15:42 ` Ian Jackson
2015-09-14 3:48 ` Juergen Gross
2015-09-14 10:36 ` George Dunlap [this message]
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=CAFLBxZbWH6LxKxuaTbcnv1rJB8ar4G_WOPfki2YzUc3QqoEszw@mail.gmail.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JFEHLIG@suse.com \
--cc=caobosimon@gmail.com \
--cc=cyliu@suse.com \
--cc=ian.campbell@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.