Re: Serial ports for Septentrio USB GNSS receiver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux