Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
Hi, On 11/09/2016 08:05 AM, Pavel Machek wrote: Hi! +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned char brightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be overridden by max_brightness property. Please submit a fix so that I could merge it with the original patch before sending it upstream. Actually... perhaps you want to wait with merging the userspace driver till the locking is solved in the LED subsystem? Maybe I'm wrong, but I have feeling that userspace driver will have unusual requirements w.r.t. locking, and that it would be good to have that solved, first... If you think about locking between led_set_brightness() and led_update_brightness() then we have no ready solution for that. Do you have any? If not then we have to live with that until one is devised. After adding the locking in brightness_show the risk of races will be only in case of concurrent calls to led_set_brightness() and led_update_brightness() from kernel, whereas currently there are no such use cases. -- Best regards, Jacek Anaszewski
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
Hi, On 11/09/2016 08:05 AM, Pavel Machek wrote: Hi! +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned char brightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be overridden by max_brightness property. Please submit a fix so that I could merge it with the original patch before sending it upstream. Actually... perhaps you want to wait with merging the userspace driver till the locking is solved in the LED subsystem? Maybe I'm wrong, but I have feeling that userspace driver will have unusual requirements w.r.t. locking, and that it would be good to have that solved, first... If you think about locking between led_set_brightness() and led_update_brightness() then we have no ready solution for that. Do you have any? If not then we have to live with that until one is devised. After adding the locking in brightness_show the risk of races will be only in case of concurrent calls to led_set_brightness() and led_update_brightness() from kernel, whereas currently there are no such use cases. -- Best regards, Jacek Anaszewski
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
Hi! > >+struct uleds_device { > >+struct uleds_user_dev user_dev; > >+struct led_classdev led_cdev; > >+struct mutexmutex; > >+enum uleds_statestate; > >+wait_queue_head_t waitq; > >+unsigned char brightness; > > I've just noticed that this is wrong, since LED subsystem > brightness type is enum led_brightness, i.e. int. > LED_FULL (255) value is a legacy enum value that can be overridden > by max_brightness property. > > Please submit a fix so that I could merge it with the original > patch before sending it upstream. Actually... perhaps you want to wait with merging the userspace driver till the locking is solved in the LED subsystem? Maybe I'm wrong, but I have feeling that userspace driver will have unusual requirements w.r.t. locking, and that it would be good to have that solved, first... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
Hi! > >+struct uleds_device { > >+struct uleds_user_dev user_dev; > >+struct led_classdev led_cdev; > >+struct mutexmutex; > >+enum uleds_statestate; > >+wait_queue_head_t waitq; > >+unsigned char brightness; > > I've just noticed that this is wrong, since LED subsystem > brightness type is enum led_brightness, i.e. int. > LED_FULL (255) value is a legacy enum value that can be overridden > by max_brightness property. > > Please submit a fix so that I could merge it with the original > patch before sending it upstream. Actually... perhaps you want to wait with merging the userspace driver till the locking is solved in the LED subsystem? Maybe I'm wrong, but I have feeling that userspace driver will have unusual requirements w.r.t. locking, and that it would be good to have that solved, first... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On 11/08/2016 08:08 PM, David Lechner wrote: On 11/8/16 5:26 AM, Jacek Anaszewski wrote: Hi David, +struct uleds_device { +struct uleds_user_devuser_dev; +struct led_classdevled_cdev; +struct mutexmutex; +enum uleds_statestate; +wait_queue_head_twaitq; +unsigned charbrightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be overridden by max_brightness property. Please submit a fix so that I could merge it with the original patch before sending it upstream. Thanks, Jacek Anaszewski The brightness should be a 32-bit integer then? Exactly. -- Best regards, Jacek Anaszewski
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On 11/08/2016 08:08 PM, David Lechner wrote: On 11/8/16 5:26 AM, Jacek Anaszewski wrote: Hi David, +struct uleds_device { +struct uleds_user_devuser_dev; +struct led_classdevled_cdev; +struct mutexmutex; +enum uleds_statestate; +wait_queue_head_twaitq; +unsigned charbrightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be overridden by max_brightness property. Please submit a fix so that I could merge it with the original patch before sending it upstream. Thanks, Jacek Anaszewski The brightness should be a 32-bit integer then? Exactly. -- Best regards, Jacek Anaszewski
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On 11/8/16 5:26 AM, Jacek Anaszewski wrote: Hi David, +struct uleds_device { +struct uleds_user_devuser_dev; +struct led_classdevled_cdev; +struct mutexmutex; +enum uleds_statestate; +wait_queue_head_twaitq; +unsigned charbrightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be overridden by max_brightness property. Please submit a fix so that I could merge it with the original patch before sending it upstream. Thanks, Jacek Anaszewski The brightness should be a 32-bit integer then?
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On 11/8/16 5:26 AM, Jacek Anaszewski wrote: Hi David, +struct uleds_device { +struct uleds_user_devuser_dev; +struct led_classdevled_cdev; +struct mutexmutex; +enum uleds_statestate; +wait_queue_head_twaitq; +unsigned charbrightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be overridden by max_brightness property. Please submit a fix so that I could merge it with the original patch before sending it upstream. Thanks, Jacek Anaszewski The brightness should be a 32-bit integer then?
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
Hi David, On 09/16/2016 09:16 PM, David Lechner wrote: This driver creates a userspace leds driver similar to uinput. New leds are created by opening /dev/uleds and writing a uleds_user_dev struct. A new leds class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner--- Documentation/leds/uleds.txt | 36 +++ drivers/leds/Kconfig | 8 ++ drivers/leds/Makefile| 3 + drivers/leds/uleds.c | 230 +++ include/uapi/linux/Kbuild| 1 + include/uapi/linux/uleds.h | 23 + 6 files changed, 301 insertions(+) create mode 100644 Documentation/leds/uleds.txt create mode 100644 drivers/leds/uleds.c create mode 100644 include/uapi/linux/uleds.h diff --git a/Documentation/leds/uleds.txt b/Documentation/leds/uleds.txt new file mode 100644 index 000..486d473 --- /dev/null +++ b/Documentation/leds/uleds.txt @@ -0,0 +1,36 @@ +Userspace LEDs +== + +The uleds driver supports userspace LEDs. This can be useful for testing +triggers and can also be used to implement virtual LEDs. + + +Usage += + +When the driver is loaded, a character device is created at /dev/uleds. To +create a new LED class device, open /dev/uleds and write a uleds_user_dev +structure to it (found in kernel public header file linux/uleds.h). + +#define LEDS_MAX_NAME_SIZE 64 + +struct uleds_user_dev { +char name[LEDS_MAX_NAME_SIZE]; +}; + +A new LED class device will be created with the name given. The name can be +any valid sysfs device node name, but consider using the LED class naming +convention of "devicename:color:function". + +The current brightness is found by reading a single byte from the character +device. Values are unsigned: 0 to 255. Reading will block until the brightness +changes. The device node can also be polled to notify when the brightness value +changes. + +The LED class device will be removed when the open file handle to /dev/uleds +is closed. + +Multiple LED class devices are created by opening additional file handles to +/dev/uleds. + +See tools/leds/uledmon.c for an example userspace program. diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 7a628c6..5fd3f4c 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -659,6 +659,14 @@ config LEDS_MLXCPLD This option enabled support for the LEDs on the Mellanox boards. Say Y to enabled these. +config LEDS_USER + tristate "Userspace LED support" + depends on LEDS_CLASS + help + This option enables support for userspace LEDs. Say 'y' to enable this + support in kernel. To compile this driver as a module, choose 'm' here: + the module will be called uleds. + comment "LED Triggers" source "drivers/leds/trigger/Kconfig" diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 3965070..d5331ff 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -75,5 +75,8 @@ obj-$(CONFIG_LEDS_MLXCPLD)+= leds-mlxcpld.o # LED SPI Drivers obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o +# LED Userspace Drivers +obj-$(CONFIG_LEDS_USER)+= uleds.o + # LED Triggers obj-$(CONFIG_LEDS_TRIGGERS)+= trigger/ diff --git a/drivers/leds/uleds.c b/drivers/leds/uleds.c new file mode 100644 index 000..59ea23e --- /dev/null +++ b/drivers/leds/uleds.c @@ -0,0 +1,229 @@ +/* + * Userspace driver for leds subsystem + * + * Copyright (C) 2016 David Lechner + * + * Based on uinput.c: Aristeu Sergio Rozanski Filho + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define ULEDS_NAME "uleds" + +enum uleds_state { + ULEDS_STATE_UNKNOWN, + ULEDS_STATE_REGISTERED, +}; + +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned char brightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
Hi David, On 09/16/2016 09:16 PM, David Lechner wrote: This driver creates a userspace leds driver similar to uinput. New leds are created by opening /dev/uleds and writing a uleds_user_dev struct. A new leds class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner --- Documentation/leds/uleds.txt | 36 +++ drivers/leds/Kconfig | 8 ++ drivers/leds/Makefile| 3 + drivers/leds/uleds.c | 230 +++ include/uapi/linux/Kbuild| 1 + include/uapi/linux/uleds.h | 23 + 6 files changed, 301 insertions(+) create mode 100644 Documentation/leds/uleds.txt create mode 100644 drivers/leds/uleds.c create mode 100644 include/uapi/linux/uleds.h diff --git a/Documentation/leds/uleds.txt b/Documentation/leds/uleds.txt new file mode 100644 index 000..486d473 --- /dev/null +++ b/Documentation/leds/uleds.txt @@ -0,0 +1,36 @@ +Userspace LEDs +== + +The uleds driver supports userspace LEDs. This can be useful for testing +triggers and can also be used to implement virtual LEDs. + + +Usage += + +When the driver is loaded, a character device is created at /dev/uleds. To +create a new LED class device, open /dev/uleds and write a uleds_user_dev +structure to it (found in kernel public header file linux/uleds.h). + +#define LEDS_MAX_NAME_SIZE 64 + +struct uleds_user_dev { +char name[LEDS_MAX_NAME_SIZE]; +}; + +A new LED class device will be created with the name given. The name can be +any valid sysfs device node name, but consider using the LED class naming +convention of "devicename:color:function". + +The current brightness is found by reading a single byte from the character +device. Values are unsigned: 0 to 255. Reading will block until the brightness +changes. The device node can also be polled to notify when the brightness value +changes. + +The LED class device will be removed when the open file handle to /dev/uleds +is closed. + +Multiple LED class devices are created by opening additional file handles to +/dev/uleds. + +See tools/leds/uledmon.c for an example userspace program. diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 7a628c6..5fd3f4c 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -659,6 +659,14 @@ config LEDS_MLXCPLD This option enabled support for the LEDs on the Mellanox boards. Say Y to enabled these. +config LEDS_USER + tristate "Userspace LED support" + depends on LEDS_CLASS + help + This option enables support for userspace LEDs. Say 'y' to enable this + support in kernel. To compile this driver as a module, choose 'm' here: + the module will be called uleds. + comment "LED Triggers" source "drivers/leds/trigger/Kconfig" diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 3965070..d5331ff 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -75,5 +75,8 @@ obj-$(CONFIG_LEDS_MLXCPLD)+= leds-mlxcpld.o # LED SPI Drivers obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o +# LED Userspace Drivers +obj-$(CONFIG_LEDS_USER)+= uleds.o + # LED Triggers obj-$(CONFIG_LEDS_TRIGGERS)+= trigger/ diff --git a/drivers/leds/uleds.c b/drivers/leds/uleds.c new file mode 100644 index 000..59ea23e --- /dev/null +++ b/drivers/leds/uleds.c @@ -0,0 +1,229 @@ +/* + * Userspace driver for leds subsystem + * + * Copyright (C) 2016 David Lechner + * + * Based on uinput.c: Aristeu Sergio Rozanski Filho + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define ULEDS_NAME "uleds" + +enum uleds_state { + ULEDS_STATE_UNKNOWN, + ULEDS_STATE_REGISTERED, +}; + +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned char brightness; I've just noticed that this is wrong, since LED subsystem brightness type is enum led_brightness, i.e. int. LED_FULL (255) value is a legacy enum value that can be
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On Thu 2016-09-22 15:43:35, Linus Walleij wrote: > On Fri, Sep 16, 2016 at 9:16 PM, David Lechnerwrote: > > > This driver creates a userspace leds driver similar to uinput. > > Just out of curiosity: what is this used for? > The typical usecase evades me, so I'd really want to know. I have RGB led connected using ESP board over ttyUSB0. I guess I'll want to keep the driver in userspace, but I still may want "normal" /sys/class/leds interface for it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On Thu 2016-09-22 15:43:35, Linus Walleij wrote: > On Fri, Sep 16, 2016 at 9:16 PM, David Lechner wrote: > > > This driver creates a userspace leds driver similar to uinput. > > Just out of curiosity: what is this used for? > The typical usecase evades me, so I'd really want to know. I have RGB led connected using ESP board over ttyUSB0. I guess I'll want to keep the driver in userspace, but I still may want "normal" /sys/class/leds interface for it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On 09/22/2016 08:43 AM, Linus Walleij wrote: On Fri, Sep 16, 2016 at 9:16 PM, David Lechnerwrote: This driver creates a userspace leds driver similar to uinput. Just out of curiosity: what is this used for? The typical usecase evades me, so I'd really want to know. Several use cases are explained in this thread: https://lkml.org/lkml/2016/7/25/505 +See tools/leds/uledmon.c for an example userspace program. Where is this program? Not in this patch for sure. Yours, Linus Walleij
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On 09/22/2016 08:43 AM, Linus Walleij wrote: On Fri, Sep 16, 2016 at 9:16 PM, David Lechner wrote: This driver creates a userspace leds driver similar to uinput. Just out of curiosity: what is this used for? The typical usecase evades me, so I'd really want to know. Several use cases are explained in this thread: https://lkml.org/lkml/2016/7/25/505 +See tools/leds/uledmon.c for an example userspace program. Where is this program? Not in this patch for sure. Yours, Linus Walleij
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On Thu, Sep 22, 2016 at 3:43 PM, Linus Walleijwrote: > On Fri, Sep 16, 2016 at 9:16 PM, David Lechner wrote: >> +See tools/leds/uledmon.c for an example userspace program. > > Where is this program? Not in this patch for sure. Ah I found it by looking a bit closer at my mail archive, sorry about the fuzz. Yours, Linus Walleij
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On Thu, Sep 22, 2016 at 3:43 PM, Linus Walleij wrote: > On Fri, Sep 16, 2016 at 9:16 PM, David Lechner wrote: >> +See tools/leds/uledmon.c for an example userspace program. > > Where is this program? Not in this patch for sure. Ah I found it by looking a bit closer at my mail archive, sorry about the fuzz. Yours, Linus Walleij
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On Fri, Sep 16, 2016 at 9:16 PM, David Lechnerwrote: > This driver creates a userspace leds driver similar to uinput. Just out of curiosity: what is this used for? The typical usecase evades me, so I'd really want to know. > +See tools/leds/uledmon.c for an example userspace program. Where is this program? Not in this patch for sure. Yours, Linus Walleij
Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
On Fri, Sep 16, 2016 at 9:16 PM, David Lechner wrote: > This driver creates a userspace leds driver similar to uinput. Just out of curiosity: what is this used for? The typical usecase evades me, so I'd really want to know. > +See tools/leds/uledmon.c for an example userspace program. Where is this program? Not in this patch for sure. Yours, Linus Walleij
[PATCH v4 1/3] leds: Introduce userspace leds driver
This driver creates a userspace leds driver similar to uinput. New leds are created by opening /dev/uleds and writing a uleds_user_dev struct. A new leds class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner--- Documentation/leds/uleds.txt | 36 +++ drivers/leds/Kconfig | 8 ++ drivers/leds/Makefile| 3 + drivers/leds/uleds.c | 230 +++ include/uapi/linux/Kbuild| 1 + include/uapi/linux/uleds.h | 23 + 6 files changed, 301 insertions(+) create mode 100644 Documentation/leds/uleds.txt create mode 100644 drivers/leds/uleds.c create mode 100644 include/uapi/linux/uleds.h diff --git a/Documentation/leds/uleds.txt b/Documentation/leds/uleds.txt new file mode 100644 index 000..486d473 --- /dev/null +++ b/Documentation/leds/uleds.txt @@ -0,0 +1,36 @@ +Userspace LEDs +== + +The uleds driver supports userspace LEDs. This can be useful for testing +triggers and can also be used to implement virtual LEDs. + + +Usage += + +When the driver is loaded, a character device is created at /dev/uleds. To +create a new LED class device, open /dev/uleds and write a uleds_user_dev +structure to it (found in kernel public header file linux/uleds.h). + +#define LEDS_MAX_NAME_SIZE 64 + +struct uleds_user_dev { +char name[LEDS_MAX_NAME_SIZE]; +}; + +A new LED class device will be created with the name given. The name can be +any valid sysfs device node name, but consider using the LED class naming +convention of "devicename:color:function". + +The current brightness is found by reading a single byte from the character +device. Values are unsigned: 0 to 255. Reading will block until the brightness +changes. The device node can also be polled to notify when the brightness value +changes. + +The LED class device will be removed when the open file handle to /dev/uleds +is closed. + +Multiple LED class devices are created by opening additional file handles to +/dev/uleds. + +See tools/leds/uledmon.c for an example userspace program. diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 7a628c6..5fd3f4c 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -659,6 +659,14 @@ config LEDS_MLXCPLD This option enabled support for the LEDs on the Mellanox boards. Say Y to enabled these. +config LEDS_USER + tristate "Userspace LED support" + depends on LEDS_CLASS + help + This option enables support for userspace LEDs. Say 'y' to enable this + support in kernel. To compile this driver as a module, choose 'm' here: + the module will be called uleds. + comment "LED Triggers" source "drivers/leds/trigger/Kconfig" diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 3965070..d5331ff 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -75,5 +75,8 @@ obj-$(CONFIG_LEDS_MLXCPLD)+= leds-mlxcpld.o # LED SPI Drivers obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o +# LED Userspace Drivers +obj-$(CONFIG_LEDS_USER)+= uleds.o + # LED Triggers obj-$(CONFIG_LEDS_TRIGGERS)+= trigger/ diff --git a/drivers/leds/uleds.c b/drivers/leds/uleds.c new file mode 100644 index 000..59ea23e --- /dev/null +++ b/drivers/leds/uleds.c @@ -0,0 +1,229 @@ +/* + * Userspace driver for leds subsystem + * + * Copyright (C) 2016 David Lechner + * + * Based on uinput.c: Aristeu Sergio Rozanski Filho + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define ULEDS_NAME "uleds" + +enum uleds_state { + ULEDS_STATE_UNKNOWN, + ULEDS_STATE_REGISTERED, +}; + +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned char brightness; + boolnew_data; +}; + +static struct miscdevice uleds_misc; + +static void uleds_brightness_set(struct led_classdev *led_cdev,
[PATCH v4 1/3] leds: Introduce userspace leds driver
This driver creates a userspace leds driver similar to uinput. New leds are created by opening /dev/uleds and writing a uleds_user_dev struct. A new leds class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner --- Documentation/leds/uleds.txt | 36 +++ drivers/leds/Kconfig | 8 ++ drivers/leds/Makefile| 3 + drivers/leds/uleds.c | 230 +++ include/uapi/linux/Kbuild| 1 + include/uapi/linux/uleds.h | 23 + 6 files changed, 301 insertions(+) create mode 100644 Documentation/leds/uleds.txt create mode 100644 drivers/leds/uleds.c create mode 100644 include/uapi/linux/uleds.h diff --git a/Documentation/leds/uleds.txt b/Documentation/leds/uleds.txt new file mode 100644 index 000..486d473 --- /dev/null +++ b/Documentation/leds/uleds.txt @@ -0,0 +1,36 @@ +Userspace LEDs +== + +The uleds driver supports userspace LEDs. This can be useful for testing +triggers and can also be used to implement virtual LEDs. + + +Usage += + +When the driver is loaded, a character device is created at /dev/uleds. To +create a new LED class device, open /dev/uleds and write a uleds_user_dev +structure to it (found in kernel public header file linux/uleds.h). + +#define LEDS_MAX_NAME_SIZE 64 + +struct uleds_user_dev { +char name[LEDS_MAX_NAME_SIZE]; +}; + +A new LED class device will be created with the name given. The name can be +any valid sysfs device node name, but consider using the LED class naming +convention of "devicename:color:function". + +The current brightness is found by reading a single byte from the character +device. Values are unsigned: 0 to 255. Reading will block until the brightness +changes. The device node can also be polled to notify when the brightness value +changes. + +The LED class device will be removed when the open file handle to /dev/uleds +is closed. + +Multiple LED class devices are created by opening additional file handles to +/dev/uleds. + +See tools/leds/uledmon.c for an example userspace program. diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 7a628c6..5fd3f4c 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -659,6 +659,14 @@ config LEDS_MLXCPLD This option enabled support for the LEDs on the Mellanox boards. Say Y to enabled these. +config LEDS_USER + tristate "Userspace LED support" + depends on LEDS_CLASS + help + This option enables support for userspace LEDs. Say 'y' to enable this + support in kernel. To compile this driver as a module, choose 'm' here: + the module will be called uleds. + comment "LED Triggers" source "drivers/leds/trigger/Kconfig" diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 3965070..d5331ff 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -75,5 +75,8 @@ obj-$(CONFIG_LEDS_MLXCPLD)+= leds-mlxcpld.o # LED SPI Drivers obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o +# LED Userspace Drivers +obj-$(CONFIG_LEDS_USER)+= uleds.o + # LED Triggers obj-$(CONFIG_LEDS_TRIGGERS)+= trigger/ diff --git a/drivers/leds/uleds.c b/drivers/leds/uleds.c new file mode 100644 index 000..59ea23e --- /dev/null +++ b/drivers/leds/uleds.c @@ -0,0 +1,229 @@ +/* + * Userspace driver for leds subsystem + * + * Copyright (C) 2016 David Lechner + * + * Based on uinput.c: Aristeu Sergio Rozanski Filho + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define ULEDS_NAME "uleds" + +enum uleds_state { + ULEDS_STATE_UNKNOWN, + ULEDS_STATE_REGISTERED, +}; + +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned char brightness; + boolnew_data; +}; + +static struct miscdevice uleds_misc; + +static void uleds_brightness_set(struct led_classdev *led_cdev, +enum led_brightness brightness) +{