linux-kernel - Re: [PATCH RFC] leds: Add support for per-LED device triggers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200712223821.742ljr4qxdrx3aqv@core.my.home>
Date:   Mon, 13 Jul 2020 00:38:21 +0200
From:   Ondřej Jirman <megous@...ous.com>
To:     Pavel Machek <pavel@....cz>
Cc:     linux-kernel@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Dan Murphy <dmurphy@...com>,
        "open list:LED SUBSYSTEM" <linux-leds@...r.kernel.org>,
        marek.behun@....cz
Subject: Re: [PATCH RFC] leds: Add support for per-LED device triggers

Hello,

On Sun, Jul 12, 2020 at 09:11:11PM +0200, Pavel Machek wrote:
> Hi!
> 

[....]

>  		}
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 2451962d1ec5..cba52714558f 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -57,6 +57,10 @@ struct led_init_data {
>  	bool devname_mandatory;
>  };
>  
> +struct led_hw_trigger_type {
> +	int dummy;
> +}
> +
>  struct led_classdev {
>  	const char		*name;
>  	enum led_brightness	 brightness;
> @@ -150,6 +154,8 @@ struct led_classdev {
>  
>  	/* Ensures consistent access to the LED Flash Class device */
>  	struct mutex		led_access;
> +
> +	struct led_hw_trigger_type *trigger_type;
>  };
>  
>  /**
> @@ -345,6 +351,9 @@ struct led_trigger {
>  	int		(*activate)(struct led_classdev *led_cdev);
>  	void		(*deactivate)(struct led_classdev *led_cdev);
>  
> +	/* LED-private triggers have this set. */
> +	struct led_hw_trigger_type *trigger_type;
> +
>  	/* LEDs under control by this trigger (for simple triggers) */
>  	rwlock_t	  leddev_list_lock;
>  	struct list_head  led_cdevs;

So after trying to use this, this seems to disallow the use of multiple HW
triggers per LED. That's fine by me, because using one HW sysfs configured
trigger per LED that use case is my proposal, but is it desireable in general?

Drivers would be forced to use just one HW trigger + sysfs config, instead
of having freedom between choosing either that or expressing multiple hw
triggering modes via multiple differently named HW triggers.

regards,
	o.

> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html