xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Ian Campbell <ian.campbell@citrix.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: Mon, 14 Sep 2015 05:48:26 +0200	[thread overview]
Message-ID: <55F6438A.7090403@suse.com> (raw)
In-Reply-To: <1441982504.3549.69.camel@citrix.com>

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.


Juergen

  parent reply	other threads:[~2015-09-14  3:48 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 [this message]
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=55F6438A.7090403@suse.com \
    --to=jgross@suse.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=ian.campbell@citrix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).