From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH V6 3/7] libxl: add pvusb API Date: Fri, 11 Sep 2015 15:41:44 +0100 Message-ID: <1441982504.3549.69.camel@citrix.com> References: <1439202928-24813-1-git-send-email-cyliu@suse.com> <1439202928-24813-4-git-send-email-cyliu@suse.com> <1441721852.24450.120.camel@citrix.com> <55F2F64F02000066000508CA@relay2.provo.novell.com> <1441978018.3549.33.camel@citrix.com> <55F2DD66.1040507@suse.com> <1441980590.3549.46.camel@citrix.com> <55F2E29D.10805@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55F2E29D.10805@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross , Chun Yan Liu , xen-devel@lists.xen.org Cc: george.dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com, Jim Fehlig , Simon Cao , wei.liu2@citrix.com List-Id: xen-devel@lists.xenproject.org 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.