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". > > > 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. > 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
