Date: Fri, 28 Mar 2003 23:05:22 +0100 From: Bernd Walter <ticso@cicely9.cicely.de> To: Bill Paul <wpaul@FreeBSD.ORG> Cc: ticso@cicely.de Subject: Re: Ax88172 vs FreeBSD USB stack Message-ID: <20030328220521.GP23168@cicely9.cicely.de> In-Reply-To: <20030328205446.BB79B37B401@hub.freebsd.org> References: <20030328193719.GN23168@cicely9.cicely.de> <20030328205446.BB79B37B401@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 28, 2003 at 12:54:46PM -0800, Bill Paul wrote: > > On Fri, Mar 28, 2003 at 11:16:55AM -0800, Maksim Yevmenkin wrote: > > > Just FYI > > > > > > ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver > > > (Bluetooth USB devices) makes use of two interfaces. > > > > >From a look into the driver these interfaces serve different > > protocols. > > I asume they are unrelated from a logical standpoint, but I don't > > know bluetooth technology. > > We have a similar situation with ulpt, where we usually have up > > to three interfaces with different capabilities. > > ulpt currently pics one of them, but we could also have three different > > ulpt instances taking each one of them. > > The uplcom driver also uses two interfaces, but in that case, they > put the interrupt endpoint on interface 0 and the bulk in/out endpoints > on interface 1. When I saw that the AX88172 manual said that the device My PL2303 has only one interface: DEVICE addr 3 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x067b idProduct=0x2303 bcdDevice=200 iManufacturer=0() iProduct=0() iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=39 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=a0 bMaxPower=100 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=3 bInterfaceClass=255 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=interrupt wMaxPacketSize=10 bInterval=1 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out bmAttributes=bulk wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=3-in bmAttributes=bulk wMaxPacketSize=64 bInterval=0 current configuration 1 Do you know which uplcom chip uses two interfaces? It's interesting, because for the long run we really need to support mutiple devices drivers for single devices and I don't want to break support for such special devices. > was supposed to have two interfaces, I wondered if maybe it had a > similar setup, but I couldn't figure out how to access the second > interface structure. For that matter, I didn't know for sure how to > tell if it actually had one. (Sometimes manuals lie.) Hopefully when I > try usbutils when I get home after work, I will learn more. The number of interfaces is in the configuration descriptor. After USB_ATTACH_START you should see it in uaa->nifaces. > > Well the AC88172 PDF is very clear about having 2 interfaces. > > The document also speaks about 4 endpoints, which I expect to be on > > interface 0 as they also have listed endpoint number 0 - they don't > > tell in the document. > > What I currently don't know is why there are 2 interfaces. > > The document also mentions some homenet capabilities on RJ11 - whatever > > it means. > > The AX88172 supports both regular ethernet and HomePNA (ethernet > over cat3 telephone wiring) transceivers. You don't need a second > USB interface for this though: you send/receive packets the same > way regardless of what kind of transceiver you have. (The ADMtek > Pegasus (if_aue) supports the same feature and only uses one set > of endpoints.) > > > Maybe it's an hardware optional interface, which is disabled in this > > special device. > > > > For the ID strings - it seems that the hardware vendor just left the > > string empty in the eeprom. > > There is a UQ_NO_STRINGS quirk for this. Perhaps I should use it. I asume it's only for devices that hang when asked. I have an ulpt device without strings that works fine: port 2 addr 3: full speed, power 98 mA, config 1, product 0x0002(0x0002), vendor 0x3980(0x3980), rev 0.06 Well - transfered data corrupts sometimes, but I doubt it hast anything to do with the strings. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030328220521.GP23168>