Ben Adler <adler@xxxxxxxxxxxxxxxxxxxxxxxxx> writes: > On 10.06.2013 20:19, Bjørn Mork wrote: >> The cdc-acm driver cannot handle those ports, but a more forgiving >> generic driver can. I don't recommend it for normal use because it >> abuses the option driver, but Ben could do a simple test like this: >> >> echo 2 >/sys/bus/usb/devices/<usbportname>/bConfigurationValue >> modprobe option >> echo 152a 8230 > /sys/bus/usb-serial/drivers/option1/new_id >> >> Unless I missed something, this should result in two /dev/ttyUSBx serial >> devices. > > Before plugging in the receiver, there's ttyUSB0 and ttyUSB1 from > another usb/serial converter device that I can't remove. Thanks a lot for your attention to detail. That comment prevented unnecessary questions about those devices. > After > plugging in, dmesg says: > >> usb 3-2: new full-speed USB device number 2 using uhci_hcd >> usb 3-2: New USB device found, idVendor=152a, idProduct=8230 >> usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 >> usb 3-2: Product: Septentrio USB Device >> usb 3-2: Manufacturer: Septentrio >> cdc_acm 3-2:1.0: ttyACM0: USB ACM device >> usbcore: registered new interface driver cdc_acm >> cdc_acm: USB Abstract Control Model driver for USB modems and ISDN > adapters > > and ttyACM0 appears. > > # echo 2 >/sys/bus/usb/devices/<usbportname>/bConfigurationValue > >> usbcore: registered new interface driver cdc_ether >> usb 3-2: bad CDC descriptors >> usb 3-2: bad CDC descriptors >> usbcore: registered new interface driver rndis_host >> usb 3-2: bad CDC descriptors >> usb 3-2: bad CDC descriptors >> usbcore: registered new interface driver rndis_wlan > > ttyACM0 is gone and no new ttyUSB* appear. Yup, that's expected. The "bad CDC descriptors" warnings should probably be silcened? They are not very useful to any end user, and only mean that these these drivers probed the device and found that it wasn't a RNDIS device. Which isn't any error, but just the way this is supposed to work. > # modprobe option > >> usbcore: registered new interface driver option >> usbserial: USB Serial support registered for GSM modem (1-port) > > # echo 152a 8230 > /sys/bus/usb-serial/drivers/option1/new_id > >> option 3-2:2.0: GSM modem (1-port) converter detected >> usb 3-2: GSM modem (1-port) converter now attached to ttyUSB2 >> option 3-2:2.1: GSM modem (1-port) converter detected >> usb 3-2: GSM modem (1-port) converter now attached to ttyUSB3 >> option 3-2:2.2: GSM modem (1-port) converter detected >> usb 3-2: GSM modem (1-port) converter now attached to ttyUSB4 >> option 3-2:2.3: GSM modem (1-port) converter detected >> usb 3-2: GSM modem (1-port) converter now attached to ttyUSB5 > > ttyUSB2 is dead > ttyUSB3 works and is connected to a port named USB1 on the receiver > ttyUSB4 is dead > ttyUSB5 works and is connected to a port named USB2 on the receiver Thanks for verifying this. I didn't expect the ttyUSB2 and ttyUSB4 devices. Thought the driver would refuse the two interfaces with no endpoints. Obviously wrong. But the fact that ttyUSB3 and ttyUSB5 works fine is what we need to know. > usb-devices now shows: > > T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 > P: Vendor=152a ProdID=8230 Rev=01.10 > S: Manufacturer=Septentrio > S: Product=Septentrio USB Device > C: #Ifs= 4 Cfg#= 2 Atr=c0 MxPwr=2mA > I: If#= 0 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option > I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option > I: If#= 2 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option > I: If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option > >> I guess this device is worth a new serial driver of its own in case that >> works? Or should we create a generic driver for 02/02/ff serial devices >> (using the inverse of the logic in drivers/net/usb/cdc_ether.c: >> usbnet_generic_cdc_bind to avoid RNDIS devices)? A few modems with such >> ports have been added to option, but a generic solution might be better. > > I obviously don't know, but would be very happy to supply further > information! I am starting to lean towards the generic 02/02/ff serial driver, but I'm not currently able to do the work so I should probably not propose it... If you are looking for a nice place to start playing with the kernel, then this is the perfect project :) You have the hardware, which makes testing a lot easier. And the driver will be very small. Some of the simpler drivers in driver/usb/serial/ can be used as examples. The main challenge will be handling the separate data interface, because you do want to match on the control interface and parse the functional descriptors there. cdc_acm and cdc_ether are examples on how to do that, but the method will have to be adapted to the usb-serial framework. Anyway, there is no harm in using the method you used above until a more suitable serial driver is found or developed. It's just not a generic solution suitable for inclusion in the kernel (in particular because of the non-functional addional ttyUSBx devices). Bjørn -- 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
