On Mon, Jun 02, 2014 at 12:24:44PM -0400, Mike Remski wrote: > On 06/02/2014 12:20 PM, Johan Hovold wrote: > > On Mon, Jun 02, 2014 at 12:02:40PM -0400, Mike Remski wrote: > >> On 06/02/2014 11:40 AM, Johan Hovold wrote: > >>> [ Please avoid top-posting. ] > >>> > >>> On Mon, Jun 02, 2014 at 11:16:11AM -0400, Mike Remski wrote: > >> lsusb -v cut for the device in question. > >> > >> Bus 005 Device 003: ID 1fdf:1001 > >> Device Descriptor: > >> bLength 18 > >> bDescriptorType 1 > >> bcdUSB 2.00 > >> bDeviceClass 239 Miscellaneous Device > >> bDeviceSubClass 2 ? > >> bDeviceProtocol 1 Interface Association > >> bMaxPacketSize0 64 > >> idVendor 0x1fdf > >> idProduct 0x1001 > >> bcdDevice 0.03 > >> iManufacturer 1 Sepura > >> iProduct 2 Colour Console > >> iSerial 0 > >> bNumConfigurations 1 > >> Configuration Descriptor: > >> bLength 9 > >> bDescriptorType 2 > >> wTotalLength 134 > >> bNumInterfaces 4 > >> bConfigurationValue 1 > >> iConfiguration 0 > >> bmAttributes 0xc0 > >> Self Powered > >> MaxPower 100mA > >> Interface Association: > >> bLength 8 > >> bDescriptorType 11 > >> bFirstInterface 0 > >> bInterfaceCount 2 > >> bFunctionClass 2 Communications > >> bFunctionSubClass 2 Abstract (modem) > > Is this indeed the right device? Then you seem to be using the wrong > > driver as this is no FTDI device, but a CDC-ACM modem-class device which > > should be driven by the cdc-acm driver. > > > >> bFunctionProtocol 0 None > >> iFunction 0 > >> Interface Descriptor: > >> bLength 9 > >> bDescriptorType 4 > >> bInterfaceNumber 0 > >> bAlternateSetting 0 > >> bNumEndpoints 1 > >> bInterfaceClass 2 Communications > >> bInterfaceSubClass 2 Abstract (modem) > >> bInterfaceProtocol 0 None > >> iInterface 0 > >> CDC Header: > >> bcdCDC 1.10 > >> CDC Call Management: > >> bmCapabilities 0x01 > >> call management > >> bDataInterface 1 > >> CDC ACM: > >> bmCapabilities 0x02 > >> line coding and serial state > >> CDC Union: > >> bMasterInterface 0 > >> bSlaveInterface 1 > >> Endpoint Descriptor: > >> bLength 7 > >> bDescriptorType 5 > >> bEndpointAddress 0x83 EP 3 IN > >> bmAttributes 3 > >> Transfer Type Interrupt > >> Synch Type None > >> Usage Type Data > >> wMaxPacketSize 0x0040 1x 64 bytes > >> bInterval 10 > >> Interface Descriptor: > >> bLength 9 > >> bDescriptorType 4 > >> bInterfaceNumber 1 > >> bAlternateSetting 0 > >> bNumEndpoints 2 > >> bInterfaceClass 10 CDC Data > >> bInterfaceSubClass 0 Unused > >> bInterfaceProtocol 0 > >> iInterface 0 > >> Endpoint Descriptor: > >> bLength 7 > >> bDescriptorType 5 > >> bEndpointAddress 0x01 EP 1 OUT > >> bmAttributes 2 > >> Transfer Type Bulk > >> Synch Type None > >> Usage Type Data > >> wMaxPacketSize 0x0040 1x 64 bytes > >> bInterval 0 > >> Endpoint Descriptor: > >> bLength 7 > >> bDescriptorType 5 > >> bEndpointAddress 0x82 EP 2 IN > >> bmAttributes 2 > >> Transfer Type Bulk > >> Synch Type None > >> Usage Type Data > >> wMaxPacketSize 0x0040 1x 64 bytes > >> bInterval 0 > >> Interface Association: > >> bLength 8 > >> bDescriptorType 11 > >> bFirstInterface 2 > >> bInterfaceCount 2 > >> bFunctionClass 2 Communications > >> bFunctionSubClass 2 Abstract (modem) > >> bFunctionProtocol 0 None > >> iFunction 0 > >> Interface Descriptor: > >> bLength 9 > >> bDescriptorType 4 > >> bInterfaceNumber 2 > >> bAlternateSetting 0 > >> bNumEndpoints 0 > > The third interface lacks endpoints and crashes the ftdi_sio driver. > > This shouldn't happen (even if you're forcing the wrong driver to bind), > > so I'll fix it up if still broken in v3.15-rc. > > > > Thanks, > > Johan > Johan, > Thanks again. Yes, the device does indeed have an FTDI embedded in it; > they've programmed in their own ids. They supply a Windows driver for > it, but that doesn't do me any good. :) Not just their own ID's it seems. Have you tried just using the cdc-acm driver? The ports should up as /dev/ttyACMx instead of ttyUSBx. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
