On Wed, 2010-02-17 at 08:01 +0100, Oliver Neukum wrote: > Am Mittwoch, 17. Februar 2010 05:54:08 schrieb Greg KH: > > On Tue, Feb 16, 2010 at 06:39:26PM -0800, Dan Williams wrote: > > > Hi, > > > > > > This short series adds some device IDs for CDMA/EVDO devices that are > > > normally driven by CDC-ACM, but also provide an additional serial port > > > that talks a proprietary Qualcomm protocol, QCDM. We now know enough of > > > QCDM to start using these ports for radio status and signal strength > > > when the CDC-ACM port is being used for PPP. > > > > Great, but how are we going to keep these devices from binding to the > > cdc-acm module if it is loaded first? Do we need to blacklist them in > > that driver at the same time? > > No, cdc-acm will not bind to vendor-specific interfaces unless the device > is in its quirk list. > > The question is why we want the huge option to just read status. In > fact, do we want a serial driver at all? Consistency. Many devices already driven by option.ko (all the Novatel ones, a few of the AnyData ones, the CDMA Huawei devices, the Dell CDMA/EVDO ones, the Kyocera ones, and a few of the ZTE ones) already have QCDM-capable ports exposed by option.ko. I don't particularly want to write two userspace codepaths to talk QCDM, one for existing devices driven by option.ko, and one for devices *not* driven by option.ko that just happen to have descriptors that look vaguely familiar but might not necessarily be what I'm looking for. When we have one driver driving these modems, that means one codepath in userspace to talk to it. Instead of two. If option.ko weren't exposing these ports, then I assume the suggestion would be to set up libusb to duplicate what option.ko is already doing WRT serial control signals and buffering? At that point, I write a bunch of libusb that does what option.ko is already doing, and then I write a bunch more to do hardware probing that option.ko is also already capable of doing. To me, adding device IDs to option is a lot easier and less error-prone in the long run. I'm also not 100% sure that the QCDM ports will always be low-speed; there appears to be an "NDIS" mode that many of the parts can operate in where PPP is not used at all, but the data goes over the QCDM port somehow instead. I'm not too concerned about that now, but if we figure out what that is in the future then the QCDM ports may need high-speed (up to 7.2Mb HSDPA and above) too. Dan -- 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
