linux-kernel - Re: [PATCH] leds: trigger/tty: feature data direction

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: <YIEuSPS11fkSwQ7N@kroah.com>
Date:   Thu, 22 Apr 2021 10:05:28 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Juergen Borleis <jbe@...gutronix.de>
Cc:     linux-leds@...r.kernel.org, Pavel Machek <pavel@....cz>,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de
Subject: Re: [PATCH] leds: trigger/tty: feature data direction

On Thu, Apr 22, 2021 at 09:47:02AM +0200, Juergen Borleis wrote:
> The current implementation just signals a visible feedback on all kind of
> activity on the corresponding TTY. But sometimes it is useful to see what
> kind of activity just happens. This change adds the capability to filter
> the direction of TTY's data flow. It enables a user to forward both
> directions to separate LEDs for tx and rx on demand. Default behavior is
> still both directions.
> 
> Signed-off-by: Juergen Borleis <jbe@...gutronix.de>
> ---
>  Documentation/leds/ledtrig-tty.rst | 47 ++++++++++++++++++++++++++
>  drivers/leds/trigger/ledtrig-tty.c | 53 +++++++++++++++++++++++++++++-
>  2 files changed, 99 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/leds/ledtrig-tty.rst
> 
> diff --git a/Documentation/leds/ledtrig-tty.rst b/Documentation/leds/ledtrig-tty.rst
> new file mode 100644
> index 00000000..6fc765c
> --- /dev/null
> +++ b/Documentation/leds/ledtrig-tty.rst
> @@ -0,0 +1,47 @@
> +===============
> +LED TTY Trigger
> +===============
> +
> +This LED trigger flashes the LED whenever some data flows are happen on the
> +corresponding TTY device. The TTY device can be freely selected, as well as the
> +data flow direction.
> +
> +TTY trigger can be enabled and disabled from user space on led class devices,
> +that support this trigger as shown below::
> +
> +	echo tty > trigger
> +	echo none > trigger
> +
> +This trigger exports two properties, 'ttyname' and 'dirfilter'. When the
> +tty trigger is activated both properties are set to default values, which means
> +no related TTY device yet and the LED would flash on both directions.
> +
> +Selecting a corresponding trigger TTY::
> +
> +	echo ttyS0 > ttyname
> +
> +This LED will now flash on data flow in both directions of 'ttyS0'.
> +
> +Selecting a direction::
> +
> +	echo in > dirfilter
> +	echo out > dirfilter
> +	echo inout > dirfilter
> +
> +This selection will flash the LED on data flow in the selected direction.
> +
> +Example
> +=======
> +
> +With the 'dirfilter' property one can use two LEDs to give a user a separate
> +visual feedback about data flow.
> +
> +Flash on data send on one LED::
> +
> +	echo ttyS0 > ttyname
> +	echo out > dirfilter
> +
> +Flash on data receive on a second LED::
> +
> +	echo ttyS0 > ttyname
> +	echo in > dirfilter
> diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
> index f62db7e..d3bd231 100644
> --- a/drivers/leds/trigger/ledtrig-tty.c
> +++ b/drivers/leds/trigger/ledtrig-tty.c
> @@ -14,6 +14,8 @@ struct ledtrig_tty_data {
>  	const char *ttyname;
>  	struct tty_struct *tty;
>  	int rx, tx;
> +	unsigned indirection:1;
> +	unsigned outdirection:1;
>  };
>  
>  static void ledtrig_tty_restart(struct ledtrig_tty_data *trigger_data)
> @@ -76,6 +78,47 @@ static ssize_t ttyname_store(struct device *dev,
>  }
>  static DEVICE_ATTR_RW(ttyname);
>  
> +static ssize_t dirfilter_show(struct device *dev,
> +			      struct device_attribute *attr, char *buf)
> +{
> +	struct ledtrig_tty_data *trigger_data = led_trigger_get_drvdata(dev);
> +
> +	if (trigger_data->indirection)
> +		return (ssize_t)sprintf(buf, "in\n");
> +	if (trigger_data->outdirection)
> +		return (ssize_t)sprintf(buf, "out\n");
> +	return (ssize_t)sprintf(buf, "inout\n");

sysfs_emit() please.

And you are adding new sysfs files, that requires an update to
Documentation/ABI/ please do so.

But why are you adding random new sysfs values to a class device?  That
feels really wrong.

thanks,

greg k-h