On Thu, Apr 14, 2011 at 02:56:34PM -0700, Greg KH wrote: > On Thu, Apr 14, 2011 at 05:42:15PM -0400, Elly Jones wrote: > > On Thu, Apr 14, 2011 at 02:25:28PM -0700, Greg KH wrote: > > > On Thu, Apr 14, 2011 at 05:09:49PM -0400, Elly Jones wrote: > > > > On Thu, Apr 14, 2011 at 01:20:57PM -0700, Greg KH wrote: > > > > > On Thu, Apr 14, 2011 at 04:12:34PM -0400, Elly Jones wrote: > > > > > > > > +#define IOCTL_QMI_GET_SERVICE_FILE (0x8BE0 + 1) > > > > > > > > +#define IOCTL_QMI_GET_DEVICE_VIDPID (0x8BE0 + 2) > > > > > > > > +#define IOCTL_QMI_GET_DEVICE_MEID (0x8BE0 + 3) > > > > > > > > +#define IOCTL_QMI_CLOSE (0x8BE0 + 4) > > > > > > > > +#define CDC_GET_ENCAPSULATED_RESPONSE 0x01A1ll > > > > > > > > +#define CDC_CONNECTION_SPEED_CHANGE 0x08000000002AA1ll > > > > > > > > > > > > > > We have IOR/IOW/etc macros for building ioctl numbers and it should be > > > > > > > using those. To start with that helps enormously for trace tools as it > > > > > > > shows the directions and sizes in the ioctl code. > > > > > > > > > > > > These ioctl numbers have to stay the same in order to remain compatible with a > > > > > > closed userspace SDK that we can't change. > > > > > > > > > > Why can't we change them? We have contacts in qualcomm and they should > > > > > work to support modemmanager properly for this device. > > > > > > > > I don't think they've made any attempts to do same, and I see no mention of it > > > > on their code aurora website. If you know someone to contact about this, I would > > > > be very interested to get in touch with them. > > > > > > > > > All of the above looks like things we don't want in the in-kernel driver > > > > > anyway, right? > > > > > > > > I agree that all of the muxing stuff belongs entirely in userspace. It is > > > > currently in kernelspace to support the closed userspace libraries. > > > > > > Then we need to remove it from the in-kernel driver. userspace will > > > follow if they really needed that functionality. > > > > Qualcomm ships their own kernel driver > > <https://www.codeaurora.org/patches/quic/gobi/Gobi3000Drivers1040_03022011.tar.gz>, > > of which this is a rewrite. I expect the actual response would be "don't use the > > upstream driver, use ours instead". > > Why would that be the response? Qualcomm has lots of kernel developers > that know how to work with the community. That's what codeaurora was > set up for? Have you tried asking them? I had not tried asking them; I had assumed (since Qualcomm sells licenses for their closed-source SDK) that they would not be thrilled with open-source support for the Gobi 2K and Gobi 3K. I have sent mail to atan@xxxxxxxxxxxxxx (the listed maintainer of their GPLed out-of-tree drivers) asking after open-source userspace support. > > > > > There's no requirement to support the closed userspace tool here, is > > > > > there? If so, who is making that requirement? > > > > > > > > There is no requirement, but Google (and presumably others) are using it, and > > > > breaking compatibility with it by changing the ioctl numbering seems like poor > > > > form. That said, it would be nice if valgrind and similar could interpret these > > > > ioctls. > > > > > > > > How would you feel about accepting both the current set of arbitrary values and > > > > a set of new ioctls generated with the IOR/IOW macros? That would preserve > > > > backwards compatibility until Google and others can move to an open set of > > > > userspace libraries. > > > > > > Nope, I'd prefer those ioctls not be present at all. And work to get > > > modemmanager to work properly would also be good, as that is the proper > > > tool to be using with this type of driver, not a closed-source mess. > > > > Alright. We're pretty much at an impasse here, so I withdraw this patch. Thank > > you, davem, and Alan Cox for your efforts in reviewing it. We will get in touch > > with someone at Qualcomm to see how they feel about an open userspace, and then > > resubmit the patch if and when same materializes. > > Impasse? Why not just take out those ioctls, get the code into the tree > so that people can use their hardware without the closed source > portions, and then, if you really need it, offer those ioctls as an > add-on patch for your users, and others if they really need it? Hm. We could do that, but the muxing-in-kernelspace would seem to be a pretty big problem even so, wouldn't it? > That way everyone benefits, right? > > thanks, > > greg k-h -- elly -- 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
