On Mon, Jan 19, 2015 at 10:54:48PM +0100, Kristian Evensen wrote: > Hi, > > On Mon, Jan 19, 2015 at 10:38 PM, Greg KH <greg@xxxxxxxxx> wrote: > > That's great, and the hid parts of the patch makes sense, keeping the > > HID driver from binding to it, but for the rest, shouldn't that just be > > a simple userspace program instead? We don't like to add kernel drivers > > that can be done in userspace, and using usbfs/libusb should be really > > simple for this device from what the driver looks like. > > > > So, care to slim down the patch a bunch and resend? > > Sure, no problem. You want a patch containing only the HID-parts? That would be great, send it to the hid maintainer and cc the list (using scripts/get_maintainer.pl should tell you the proper people to send it to.) > My reason for adding this as a kernel driver was to ease usage of the > device in scenarios where using libusb is not possible or desirable. > For example embedded devices with space constraints or being able to > restart USB ports from Bash-scripts. One use-case I have had for the > driver is a script which monitors AT-modems by sending "AT" to the > serial device, and restart the port by pipeing a value into portX if > no reply has been received for a certain amount of time. If you can run a bash script, you should be able to run a tiny binary as well that handles this type of thing. We don't like adding custom, non-documented apis to the kernel like this if at all possible, especially ones that can be handled with userspace programs instead. 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
