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
