Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

2015-01-19 Thread Kristian Evensen
Hi,

On Mon, Jan 19, 2015 at 10:38 PM, Greg KH g...@kroah.com 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?

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.

-Kristian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

2015-01-19 Thread Greg KH
On Mon, Jan 19, 2015 at 08:32:26PM +0100, Kristian Evensen wrote:
 The Yepkit YKUSH https://www.yepkit.com/products/ykush is a three-port
 switchable USB hub. In addition the to actual hub device, an HID device is
 exported (VID 0x04D8 PID 0x0042). By sending specific commands to the HID
 device, it is possible to power up/down the three ports separately or all 
 ports
 together. Commands 0x01-0x03 is used to power down ports 1-3, while 0x0A is 
 used
 to power down all ports. In order to power up a port (or all ports), the 
 command
 is OR'd with 0x10.

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?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html