On Tue, May 18, 2010 at 04:57:37PM -0600, Steve McKown wrote: > On Tuesday 18 May 2010 08:55:39 am Greg KH wrote: > > On Tue, May 18, 2010 at 08:44:59AM -0600, Steve McKown wrote: > > > > Wait, this isn't the standard Linux GPIO layer. What happened to using > > > > that instead of a custom ioctl? > > > > > > It's already on my todo list; I just haven't got to it yet. > > > > Ok, that's the big change that I would like to see happen. > > I'll have it before I next post code for review. Great. > > I don't want > > to add new ioctls to the kernel if at all possible, especially one-off > > ones like this that only work for one specific driver/device. > > A few ioctls remain in the patch even after porting to kernel gpio: > > - Get and set port configuration. Defines the configuration of the > internal port pins on the cp210x. This includes things like > pull-ups, pin function, reset state, etc. This is all dynamic? Nice. > - Set VID, PID and descriptors: product, serial, and device version. You can dynamically change the vid and pid and stuff? Heh, that's going to be fun to track :) Those all could be done with sysfs files, right? > We use these ioctls to properly configure the cp210x embedded in several of > our USB device designs. Currently, the patch includes cp210x.h which can be > included from userspace too, so that the ioctl commands, starting at > SIOCDEVPRIVATE, can be known without defining new ioctls globally. Is this > enough isolation to consider their inclusion? If no, what other methods > could be considered? configfs was created for configuring things, perhaps you might want to look into using that? Or, if they are single value things, like the vid/pid and such, then a writable sysfs file also would work well, and be much simpler than an ioctl for userspace to control. 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
