All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Florian Eckert <fe@dev.tdt.de>,
	u.kleine-koenig@pengutronix.de, gregkh@linuxfoundation.org,
	pavel@ucw.cz, lee@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
	Eckert.Florian@googlemail.com
Subject: Re: [PATCH 2/2] leds: trigger: ledtrig-tty: add additional modes
Date: Tue, 14 Feb 2023 08:54:06 +0100	[thread overview]
Message-ID: <b5dd2505-b087-b521-739b-ad4e97f3cbc5@kernel.org> (raw)
In-Reply-To: <20230213140638.620206-3-fe@dev.tdt.de>

On 13. 02. 23, 15:06, Florian Eckert wrote:
> Add additional modes to trigger the selected LED.
> The following modes are supported:
> 
> TD/RD:	Flash LED on data transmission (default)
> CTS:	DCE Ready to accept data from the DTE.
> DSR:	DCE is ready to receive and send data.
> CAR:	DCE is receiving a carrier from a remote DTE.
> RNG:	DCE has detected an incoming ring signal.
> 
> The mode can be changed for example with the following command:
> echo "CTS" /sys/class/leds/<led>/mode

This will emit only:
CTS /sys/class/leds/<led>/mode

> This would turn on the LED, when the DTE(modem) signals the DCE that it
> is ready to accept data.
> 
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
...
> --- a/drivers/leds/trigger/ledtrig-tty.c
> +++ b/drivers/leds/trigger/ledtrig-tty.c
> @@ -7,6 +7,14 @@
>   #include <linux/tty.h>
>   #include <uapi/linux/serial.h>
>   
> +enum tty_led_mode {
> +	TTY_LED_CNT,
> +	TTY_LED_CTS,
> +	TTY_LED_DSR,
> +	TTY_LED_CAR,
> +	TTY_LED_RNG,
> +};
> +
>   struct ledtrig_tty_data {
>   	struct led_classdev *led_cdev;
>   	struct delayed_work dwork;
> @@ -14,6 +22,15 @@ struct ledtrig_tty_data {
>   	const char *ttyname;
>   	struct tty_struct *tty;
>   	int rx, tx;
> +	unsigned int mode;

Why not the enum then?

> +};
> +
> +static const char * const mode[] = {

This is not a wise name.

> +	[TTY_LED_CNT] = "TD/RD", // Trasmit Data / Receive Data
> +	[TTY_LED_CTS] = "CTS", // CTS Clear To Send
> +	[TTY_LED_DSR] = "DSR", // DSR Data Set Ready
> +	[TTY_LED_CAR] = "CAR", // CAR Data Carrier Detect (DCD)
> +	[TTY_LED_RNG] = "RNG", // RNG Ring Indicator (RI)
>   };
>   
>   static void ledtrig_tty_restart(struct ledtrig_tty_data *trigger_data)
> @@ -21,6 +38,74 @@ static void ledtrig_tty_restart(struct ledtrig_tty_data *trigger_data)
>   	schedule_delayed_work(&trigger_data->dwork, 0);
>   }
>   
> +static ssize_t mode_show(struct device *dev,
> +			 struct device_attribute *attr, char *buf)
> +{
> +	struct ledtrig_tty_data *trigger_data = led_trigger_get_drvdata(dev);
> +	enum tty_led_mode tty_mode;
> +
> +	mutex_lock(&trigger_data->mutex);
> +	tty_mode = trigger_data->mode;
> +	mutex_unlock(&trigger_data->mutex);
> +
> +	switch (tty_mode) {
> +	case TTY_LED_CTS:
> +		return sprintf(buf, "%s [%s] %s %s %s\n", mode[TTY_LED_CNT],
> +				mode[TTY_LED_CTS], mode[TTY_LED_DSR],
> +				mode[TTY_LED_CAR], mode[TTY_LED_RNG]);
> +	case TTY_LED_DSR:
> +		return sprintf(buf, "%s %s [%s] %s %s\n", mode[TTY_LED_CNT],
> +				mode[TTY_LED_CTS], mode[TTY_LED_DSR],
> +				mode[TTY_LED_CAR], mode[TTY_LED_RNG]);
> +	case TTY_LED_CAR:
> +		return sprintf(buf, "%s %s %s [%s] %s\n", mode[TTY_LED_CNT],
> +				mode[TTY_LED_CTS], mode[TTY_LED_DSR],
> +				mode[TTY_LED_CAR], mode[TTY_LED_RNG]);
> +	case TTY_LED_RNG:
> +		return sprintf(buf, "%s %s %s %s [%s]\n", mode[TTY_LED_CNT],
> +				mode[TTY_LED_CTS], mode[TTY_LED_DSR],
> +				mode[TTY_LED_CAR], mode[TTY_LED_RNG]);
> +	case TTY_LED_CNT:
> +	default:
> +		return sprintf(buf, "[%s] %s %s %s %s\n", mode[TTY_LED_CNT],
> +				mode[TTY_LED_CTS], mode[TTY_LED_DSR],
> +				mode[TTY_LED_CAR], mode[TTY_LED_RNG]);

Can't we do the above in a loop easier?

> +static ssize_t mode_store(struct device *dev,
> +			  struct device_attribute *attr, const char *buf,
> +			  size_t size)
> +{
> +	struct ledtrig_tty_data *trigger_data = led_trigger_get_drvdata(dev);
> +	ssize_t ret = size;
> +	enum tty_led_mode tty_mode;
> +
> +	/* Check for new line in string*/
> +	if (size > 0 && buf[size - 1] == '\n')
> +		size -= 1;
> +
> +	if (strncmp(buf, mode[TTY_LED_CTS], size) == 0)
> +		tty_mode = TTY_LED_CTS;
> +	else if (strncmp(buf, mode[TTY_LED_DSR], size) == 0)
> +		tty_mode = TTY_LED_DSR;
> +	else if (strncmp(buf, mode[TTY_LED_CAR], size) == 0)
> +		tty_mode = TTY_LED_CAR;
> +	else if (strncmp(buf, mode[TTY_LED_RNG], size) == 0)
> +		tty_mode = TTY_LED_RNG;
> +	else if (strncmp(buf, mode[TTY_LED_CNT], size) == 0)
> +		tty_mode = TTY_LED_CNT;
> +	else
> +		return -EINVAL;

Again, a loop?

> +
> +	mutex_lock(&trigger_data->mutex);
> +	trigger_data->mode = tty_mode;
> +	mutex_unlock(&trigger_data->mutex);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RW(mode);
> +
>   static ssize_t ttyname_show(struct device *dev,
>   			    struct device_attribute *attr, char *buf)
>   {
> @@ -76,6 +161,18 @@ static ssize_t ttyname_store(struct device *dev,
>   }
>   static DEVICE_ATTR_RW(ttyname);
>   
> +static void ledtrig_tty_flags(struct ledtrig_tty_data *trigger_data,
> +		unsigned int flag)
> +{
> +	unsigned int status;
> +
> +	status = tty_get_mget(trigger_data->tty);

So what about negative values = errors?

> +	if (status & flag)

They really might hit here.

> +		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> +	else
> +		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> +}
> +


thanks,
-- 
js
suse labs


  reply	other threads:[~2023-02-14  7:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 14:06 [PATCH 0/2] leds: ledtrig-tty: mode xtension Florian Eckert
2023-02-13 14:06 ` [PATCH 1/2] tty: new helper function tty_get_mget Florian Eckert
2023-02-13 19:25   ` kernel test robot
2023-02-13 19:25   ` kernel test robot
2023-02-13 21:28   ` kernel test robot
2023-02-13 21:49   ` kernel test robot
2023-02-14  7:41   ` Jiri Slaby
2023-02-14  9:17     ` Florian Eckert
2023-02-13 14:06 ` [PATCH 2/2] leds: trigger: ledtrig-tty: add additional modes Florian Eckert
2023-02-14  7:54   ` Jiri Slaby [this message]
2023-02-14 11:13     ` Florian Eckert
2023-02-16  6:45       ` Jiri Slaby
2023-02-14 10:11   ` Uwe Kleine-König
2023-02-14 10:48     ` Florian Eckert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5dd2505-b087-b521-739b-ad4e97f3cbc5@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=Eckert.Florian@googlemail.com \
    --cc=fe@dev.tdt.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.