On Fri, 2011-04-15 at 11:31 +0100, Alan Cox wrote: > > > There are multiple ways to skin a cat > > > > Meaning that you do not strongly object to keeping the muxing in kernelspace? > > If it makes sense in general, as opposed to "solely to support some > proprietary bits" It might, but first we'd have to reverse-engineer the bits of QMI that qualcomm hasn't disclosed yet. There's some of the protocol basics already in the driver but the rest of it is known only the proprietary userspace. Given Qualcomm's track record with protocols I seriously doubt they will just throw up a PDF of all the QMI bits so that people don't have to use their (supposedly horrible) QCWWAN2K.so. Basically, QMI lets you control the card the same way AT commands would, but the Gobi firmware doesn't implement a full suite of AT commands, and you have to use QMI to access full functionality. That doesn't mean was *shouldn't* commit some sort of driver for the Gobi network part, since that's still very useful, but perhaps the /dev/qmi bits and private ioctls shouldn't go in without further discussion about exactly how that interface should look. Incidentally, this is the same reason the Qualcomm GPU driver got a lot of discussion, because they had some random kernel API for accessing the 3D blocks or memory manager that they didn't want to document or disclose. In the case of the Gobi driver though, that proprietary API bits are easily separable from the rest. 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
