[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170717163458.GA1920@nanopsycho.orion>
Date: Mon, 17 Jul 2017 18:34:58 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, davem@...emloft.net,
mchehab@...nel.org, jikos@...nel.org
Subject: Re: [patch 0/2] add actuators support
Mon, Jul 17, 2017 at 06:28:38PM CEST, gregkh@...uxfoundation.org wrote:
>On Mon, Jul 17, 2017 at 06:19:12PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> I am owner of height adjustable desk and naturally, as it has an USB
>> interface, I need to controll it from my computer. Started to think
>> about what would be the best way, I realized that I need to introduce
>> a new driver class in kernel. The reason is a need to have one API
>> for all possible kinds of actuator devices (USB, I2C, gpio, etc).
>
>Why does this have to be a kernel driver at all? Your USB driver should
>really just be a simple userspace application (use libusb to have it
>work on all operating systems.)
Yeah, I was thinking about it as well. To have some kind of single
purpose app like sispmctl (control of surge protector). But that would
limit you only for this specific device. And for multiple devices you
would have to have multiple apps.
So it seems to me like a suitable solution to have this as a driver
class.
>
>While the idea of a "generic class" is nice, given that there is only
>one device of this type out there so far, and it's a USB one, kind of
>implies that a generic class isn't needed just yet.
We have to start somewhere. The world is full of actuators. Connected
over diferent buses. I think it is good to have a class,lib,app so the
drivers could be easily added, apps could be written using single api.
>
>Oh, and it's nice to cc: the linux-usb@...r mailing list for USB patches
>in the future :)
Will do.
>
>thanks,
>
>greg k-h
Powered by blists - more mailing lists