Re: [PATCH] Add Qualcomm Gobi 2000/3000 driver.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

thanks,

greg k-h
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux