[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API
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? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |