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@xxxxxxxxxxxxxx>
> ---
> 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
