On Mon, 20 Aug 2012, Brian Buhrow wrote: > Hello. I'm working on a driver for the Novatel 551L USB data modem > from Verizon. This is a device that looks like an ethernet port (cdce(4)) > on one interface, and a modem on another (u3g(4)). The easiest tack strikes > me as modifying the cdce(4) driver to attach an ucom device to itself in the > event there is such an interface to attach to. For the initial attempt, I > match the device on the product and vendor IDs
> This works fine, but what happens now is that all of the interrfaces > on the device match the cdce(4) driver, and I get 4 instances of the driver > running at once. I've been trying to use the u3g.c driver as a model of > how to configure multiple interfaces on a device, but there seem to be some > inconsistencies about how the various usb drivers initialize themselves, > and I'm not entirely sure I know which code does what. The cdce driver attaches to USB "interface" directly (see files.usb, it are at usbifif) the u3g_init driver attaches at the USB "device" level (see files.usb, it is at usbdevif) and claims the whole device, which then detaches and comes back with a different personality.. but then the u3g driver only attaches to the USB "interface" it requires. > Can someone point me at a good code example in our tree of a driver that > claims multiple interfaces on a usb device and maybe even at the lines > that do the claiming? I have written two drivers, ubt(4) and uhso(4) that both attach the whole device and use multiple USB interfaces internally. uhso in fact provides several com ports and a network interface so that might be more useful to you. uhso(4) and u3g(4) have an additional complication in that the device does not work initially, it initially appears as a umass device and requires a host driver (windows and macos drivers stored on the 'cd') to twiddle something to turn it into modem mode. > I've been successful at getting the attaches to work, but not at > telling the config code that I have all the interfaces for this device, > thank you very much. that is handled in files.usb .. when a USB device is discovered, the USB stack first offers it to 'usbdevif' drivers as a 'device' and if no driver claims it, offers each 'interface' individually to 'usbifif' drivers, and any left unclaimed will appear as ugen(4) > For those that care, I'm basing my work on the fact that the Linux > folks seem to have these Qualcomm Gobi based devices working by twiddling > the modems with some python scripts before they fire up dhcp clients > against the ethernet side of these devices. sometimes you have to do that; the UHSO devices require some proprietary AT commands to be sent on the control port in order to set up the network interface but I generally just use pppd on the modem port directly since it handles that internally. regards, iain
