Re: Tips on programming usb devices?

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Thu, 6 Sep 2012, Brian Buhrow wrote:

>       For those of you who haven't been following the thread, I'm working on
> a driver for the Novatel 551L USB modem.  I believe this device is based on
> the Qualcomm Gobi 3,000 chip set and features a multi-interface USB device.

do you know if this would cover the mini-PCIe board too? I understood some
mini-PCIe boards show up as USB hubs..

> The first 4 interfaces present themselves as  general communications ports,
> of which the first permits standard serial connections through which modem
> Hayes style AT commands can be sent to control the modem's behavior.   The
> other 3 ports are available and, I believe, work, but I don't know how to
> use them.

one of them may be a GPS port.. the uhso devices seem to also have these
(though mine does not)

> The last 2 interfaces look like a cdce(4) ethernet device, which once
> the modem is activated, responds to dhcp client requests and allows IP
> traffic to flow in and out through the device.

I am not sure if you are using 'interfaces' to mean 'USB interfaces' here,
or to just mean a general IO method?

>       The driver I have, which runs under NetBSD-5, is essentially a
> mash up of the u3g(4) and cdce(4) drivers.  It attaches the first four
> interfaces as serial ports using the ucom(4) driver and presents an
> ethernet interface to the system for the last two interfaces.  The Linux
> folks have chosen to extend their cdce kernel driver to allow it to
> attach serial ports on selected devices.  Because I was learning how to
> do USB programming on this project, I elected to implement a stand-alone
> driver.  The new driver, which I'm calling ugobi(4), can support other
> devices of this nature, I'm thinking of devices like the LG Vl600 or the
> Pantech 290.  I can think of three ways to approach this issue, which is
> where I'd like feedback.  Here are my thoughts:
>
> 1.  Keep the ugobi(4) driver as it is and commit it as a new USB driver,
> complete with manual page and sample scripts showing how to activate the
> modem through the At modem interface.  Then, as more folks encounter these
> modems, they can easily add them to this driver.

essentially that is what I did for uhso(4), though in that case the
network interface was not the same as CDCE, and some of the serial ports
were not the same as umodem

> 2.  Extend the cdce(4) driver to look for flags in device specific entries
> telling it to attach serial ports in addition to the ethernet interface.
> this seems somehow unclean to me, though it was my original idea to do this
> when I started this project.

I don't think this is any good; the cdce driver only attaches to a "USB
interface" in any case, it has no knowledge of the other interfaces that
the device may provide..

> 3.  Extend the umodem(4) driver to attach the unclaimed interfaces of these
> modems as serial ports.  This seems like the cleanest approach from a code
> development perspective, but could cause a little confusion in practical
> usage, as it could be more challenging to match up which serial ports go
> with which ethernet interfaces.  (Approach 1 doesn't have this problem
> because the name of the base driver shows up on the same line as all the
> sub-devices when the thing probes, see below.)

and this is much the same; umodem driver attaches to a "USB interface"
only, so I don't see how that can work..?

> 4.  Another approach I haven't thought of?

If the interface code is exactly the same as the CDCE driver, then you
could modify the cdce(4) driver, so that the USB attachment code is a
wrapper around cdce_ifattach() calls for example.. then you can use the
same cdce_ifattach() call from your ugobi.c driver..  if that makes sense?
Then the ugobi(4) driver is basically a wrapper which attaches to the base
device, and attaches the appropriate com/cdce drivers to it

> Here's the output from dmesg for the new device.
>
> ugobi0 at uhub3 port 4
> ugobi0: Novatel Wireless, Inc. Novatel Wireless 4G, rev 2.00/0.15, addr 2
> ucom0 at ugobi0 portno 0: uGobi Serial Device
> ucom1 at ugobi0 portno 1: uGobi Serial Device
> ucom2 at ugobi0 portno 2: uGobi Serial Device
> ucom3 at ugobi0 portno 3: uGobi Serial Device

do you know if the ports have specific functions? with uhso(4) there is a
clear declaration of what the ports are for, so I embedded that into the
autoconf messages, eg

 uhso0 at uhub0 port 2
 uhso0: Option N.V. Globetrotter HSDPA Modem, rev 1.10/0.00, addr 2
 uhso0: Control (port 0) attached as mux tty
 uhso0: Application (port 3) attached as mux tty
 uhso0: Network (port 11) attached as ifnet
 uhso0: Diagnostic (port 1) attached as bulk tty
 uhso0: Modem (port 8) attached as bulk tty

and then you can infer that /dev/ttyHS0.08 is the "Modem"

iain