On Wed, Oct 22, 2014 at 01:17:44PM +0200, Andreas Sundstrom wrote: > Some newer switch models from HP has a usb2serial port in them. > I just got to try one out and it sort of works with the generic > usbserial driver. > > The problem I am seeing is that it always use 9600 bps, even if I > specify 115200 or 19200. > > Is it possible to troubleshoot this in any way, I can test patches if > needed. > This is on a vanilla 3.17.1 kernel. > > Here are the details: > modprobe usbserial vendor=0x3f0 product=0x13f > > [ 188.018495] usbcore: registered new interface driver usbserial > [ 188.018522] usbcore: registered new interface driver usbserial_generic > [ 188.018547] usbserial: USB Serial support registered for generic > [ 188.018575] usbserial_generic 3-2:1.0: Generic device with no bulk > out, not allowed. > [ 188.018591] usbserial_generic: probe of 3-2:1.0 failed with error -5 > [ 188.018607] usbserial_generic 3-2:1.1: The "generic" usb-serial > driver is only for testing and one-off prototypes. > [ 188.018612] usbserial_generic 3-2:1.1: Tell linux-usb@xxxxxxxxxxxxxxx > to add your device to a proper driver. > [ 188.018617] usbserial_generic 3-2:1.1: generic converter detected > [ 188.018828] usb 3-2: generic converter now attached to ttyUSB0 > > root@computer:/tmp# lsusb -vvv -d 03f0:013f > > Bus 003 Device 003: ID 03f0:013f Hewlett-Packard > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 64 > idVendor 0x03f0 Hewlett-Packard > idProduct 0x013f > bcdDevice 0.01 > iManufacturer 1 HP > iProduct 2 HPN Serial Port > iSerial 3 A7735230001 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 75 > bNumInterfaces 2 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x20 > (Missing must-be-set bit!) > (Bus Powered) > Remote Wakeup > MaxPower 100mA > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 0 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 2 Abstract (modem) > 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 1 AT-commands (v.25ter) > iInterface 0 > CDC Header: > bcdCDC 1.10 > CDC ACM: > bmCapabilities 0x06 > sends break > line coding and serial state > CDC Union: > bMasterInterface 0 > bSlaveInterface 1 > CDC Call Management: > bmCapabilities 0x01 > call management > bDataInterface 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 2 > 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 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Device Status: 0x0000 > (Bus Powered) Looks like this one should be handled by the cdc-acm driver, but the device class (Misc) prevents it from being recognised. Can you try forcing it to bind through sysfs? echo 03f0 013f >/sys/bus/usb/drivers/cdc_acm/new_id Thanks, 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