[PATCH v7 0/2] leds: ledtrig-tty: add tty_led_mode xtension

[PATCH v7 0/2] leds: ledtrig-tty: add tty_led_mode xtension

[Florian Eckert]

Hello,

here commes v7 of this series to add additional tty_led_modes.

v7:
Changes compared to the v5 patchset with
20230222075539.484878-1-fe@dev.tdt.de are.

Addressed review comments by Jiri Slaby are:

Thanks for the hint with the command 'make htmldocs SPHINXDIRS="admin-guide"'.
Unfortunately, I did not know that. I have now verified it also in the
browser. In my opinion, the list is now also displayed correctly in
the documentation.


v6:
Changes compared to the v5 patchset with
20230221081901.15557-1-fe@dev.tdt.de are.

Addressed review comments by kernel test robot are:

* fix Documentation/ABI/testing/sysfs-class-led-trigger-tty:9:
  WARNING: Unexpected indentation.
* fix Documentation/ABI/testing/sysfs-class-led-trigger-tty:9:
  WARNING: Block quote ends without a blank line; unexpected unindent.

Thanks to Jiri Slaby, who gave me the crucial hint of what I need to fix,
to possibly make the 'Kernel test robot' happy.


v5:
Changes compared to the v4 patchset with
20230220152038.3877596-1-fe@dev.tdt.de are.

Sorry for the inconvenience, but I sent the wrong patch for
ledtrig-tty.c in v4. The v5 patchset now includes all the changes I
specified in the v4 patchset.


v4:
Changes compared to the v3 patchset with
20230220093739.320478-1-fe@dev.tdt.de are.

Addressed review comments by Jiri Slaby are:

ledtrig-tty.c:
- Do not use __TTY_LED_MAX pattern us instead __TTY_LED_LAST = TTY_LED_RNG
- Move declartion and assignment into one singel line
- Use __TTY_LED_LAST pattern, to simplify tty_mode_show and
  tty_mode_store handling


v3:
Changes compared to the v2 patchset with
20230217094403.1574468-1-fe@dev.tdt.de are.

Addressed review comments by Greg K-H are:

tty.h:
- Fix first comment line and remark -%ENOTTY for the new function
  'tty_get_mget' to make a proper kernel doc.
- Add the return value -%ENOTTY again, I thought it was no longer needed.


v2:
Changes compared to the initial patchset with
20230213140638.620206-1-fe@dev.tdt.de are.

Addressed review comments by Jiri Slaby are:

tty.h:
- Fix compilation error because of wrong rebaseing
- Remove empty lines
- Use new 'tty_get_mget' in 'tty_tiocmget'

ledtrig-tty.c:
- Update commit description
- Use enum for tty_led_mod in struct ledtrig_tty_date
- Rename sysfs file from 'mode' to 'tty_led_mode'
- Change tty_led_mode show function to use loop instead of switch/case
- Change tty_led_mode store function to use loop instead of switch/case
- Check return value of function tty_get_mget


Florian Eckert (2):
  tty: new helper function tty_get_mget
  trigger: ledtrig-tty: add additional modes

 .../ABI/testing/sysfs-class-led-trigger-tty   |  17 ++
 drivers/leds/trigger/ledtrig-tty.c            | 145 ++++++++++++++++--
 drivers/tty/tty_io.c                          |  28 +++-
 include/linux/tty.h                           |   1 +
 4 files changed, 170 insertions(+), 21 deletions(-)

-- 
2.30.2

[PATCH v7 1/2] tty: new helper function tty_get_mget

[Florian Eckert]

For a given struct tty_struct, this provides the appropriate tty line
state flags needed to add more modes to the ledtrig-tty trigger.

The new function is then used to get via tty_tiocmget() the different tty
line states.

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
 drivers/tty/tty_io.c | 28 ++++++++++++++++++++++------
 include/linux/tty.h  |  1 +
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3149114bf130..a068b03a0828 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2493,6 +2493,24 @@ static int send_break(struct tty_struct *tty, unsigned int duration)
 	return retval;
 }
 
+/**
+ * tty_get_mget		-	get modem status
+ * @tty: tty device
+ *
+ * Obtain the modem status bits from the tty driver if the feature
+ * is supported. Return -%ENOTTY if it is not available.
+ */
+int tty_get_mget(struct tty_struct *tty)
+{
+	int retval = -ENOTTY;
+
+	if (tty->ops->tiocmget)
+		retval = tty->ops->tiocmget(tty);
+
+	return retval;
+}
+EXPORT_SYMBOL_GPL(tty_get_mget);
+
 /**
  * tty_tiocmget		-	get modem status
  * @tty: tty device
@@ -2505,14 +2523,12 @@ static int send_break(struct tty_struct *tty, unsigned int duration)
  */
 static int tty_tiocmget(struct tty_struct *tty, int __user *p)
 {
-	int retval = -ENOTTY;
+	int retval;
 
-	if (tty->ops->tiocmget) {
-		retval = tty->ops->tiocmget(tty);
+	retval = tty_get_mget(tty);
+	if (retval >= 0)
+		retval = put_user(retval, p);
 
-		if (retval >= 0)
-			retval = put_user(retval, p);
-	}
 	return retval;
 }
 
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 730c3301d710..825186c0fec1 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -421,6 +421,7 @@ int tty_unthrottle_safe(struct tty_struct *tty);
 int tty_do_resize(struct tty_struct *tty, struct winsize *ws);
 int tty_get_icount(struct tty_struct *tty,
 		struct serial_icounter_struct *icount);
+int tty_get_mget(struct tty_struct *tty);
 int is_current_pgrp_orphaned(void);
 void tty_hangup(struct tty_struct *tty);
 void tty_vhangup(struct tty_struct *tty);
-- 
2.30.2

[PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Florian Eckert]

Add additional modes to trigger the selected LED.
The following modes are supported:

Tx/Rx:	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 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>
---
 .../ABI/testing/sysfs-class-led-trigger-tty   |  17 ++
 drivers/leds/trigger/ledtrig-tty.c            | 145 ++++++++++++++++--
 2 files changed, 147 insertions(+), 15 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-tty b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
index 2bf6b24e781b..1c28e6c61d19 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-tty
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
@@ -4,3 +4,20 @@ KernelVersion:	5.10
 Contact:	linux-leds@vger.kernel.org
 Description:
 		Specifies the tty device name of the triggering tty
+
+What:		/sys/class/leds/<led>/mode
+Date:		January 2023
+KernelVersion:	6.3
+Description:
+		Specifies the operating to trigger the LED.
+		The following operating modes are supported:
+
+		* Tx/Rx: Flash LED on data transmission (default)
+		* CTS:   DCE Ready to accept data from the DTE.
+		  LED on if line is high.
+		* DSR:   DCE is ready to receive and send data.
+		  LED on if line is high.
+		* CAR:   DCE has detected a carrier from a remote DTE.
+		  LED on if line is high.
+		* RNG:   DCE has detected an incoming ring signal.
+		  LED on if line is high.
diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
index f62db7e520b5..7c4c171c8745 100644
--- a/drivers/leds/trigger/ledtrig-tty.c
+++ b/drivers/leds/trigger/ledtrig-tty.c
@@ -7,6 +7,15 @@
 #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,
+	__TTY_LED_LAST = TTY_LED_RNG
+};
+
 struct ledtrig_tty_data {
 	struct led_classdev *led_cdev;
 	struct delayed_work dwork;
@@ -14,6 +23,15 @@ struct ledtrig_tty_data {
 	const char *ttyname;
 	struct tty_struct *tty;
 	int rx, tx;
+	enum tty_led_mode mode;
+};
+
+static const char * const mode[] = {
+	[TTY_LED_CNT] = "Tx/Rx", // 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 +39,70 @@ static void ledtrig_tty_restart(struct ledtrig_tty_data *trigger_data)
 	schedule_delayed_work(&trigger_data->dwork, 0);
 }
 
+static ssize_t ledtrig_tty_mode_show(char *buf, enum tty_led_mode tty_mode)
+{
+	int len = 0;
+	int i;
+
+	for (i = 0; i <= __TTY_LED_LAST; i++) {
+		bool hit = tty_mode == i;
+		bool last = i == __TTY_LED_LAST;
+
+		len += sysfs_emit_at(buf, len, "%s%s%s%s",
+				  hit ? "[" : "",
+				  mode[i],
+				  hit ? "]" : "",
+				  last ? "" : " ");
+	}
+
+	len += sysfs_emit_at(buf, len, "\n");
+
+	return len;
+}
+
+static ssize_t tty_led_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);
+
+	return ledtrig_tty_mode_show(buf, tty_mode);
+}
+
+static ssize_t tty_led_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 = __TTY_LED_LAST;
+	int i;
+
+	/* Check for new line in string*/
+	if (size > 0 && buf[size - 1] == '\n')
+		size -= 1;
+
+	for (i = 0; i <= __TTY_LED_LAST; i++)
+		if (strncmp(buf, mode[i], size) == 0) {
+			tty_mode = i;
+			break;
+		}
+
+	if (i > __TTY_LED_LAST)
+		return -EINVAL;
+
+	mutex_lock(&trigger_data->mutex);
+	trigger_data->mode = tty_mode;
+	mutex_unlock(&trigger_data->mutex);
+
+	return ret;
+}
+static DEVICE_ATTR_RW(tty_led_mode);
+
 static ssize_t ttyname_show(struct device *dev,
 			    struct device_attribute *attr, char *buf)
 {
@@ -76,6 +158,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);
+	if (status & flag)
+		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
+	else
+		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
+}
+
 static void ledtrig_tty_work(struct work_struct *work)
 {
 	struct ledtrig_tty_data *trigger_data =
@@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
 		trigger_data->tty = tty;
 	}
 
-	ret = tty_get_icount(trigger_data->tty, &icount);
-	if (ret) {
-		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
-		mutex_unlock(&trigger_data->mutex);
-		return;
-	}
-
-	if (icount.rx != trigger_data->rx ||
-	    icount.tx != trigger_data->tx) {
-		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
-
-		trigger_data->rx = icount.rx;
-		trigger_data->tx = icount.tx;
-	} else {
-		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
+	switch (trigger_data->mode) {
+	case TTY_LED_CTS:
+		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
+		break;
+	case TTY_LED_DSR:
+		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
+		break;
+	case TTY_LED_CAR:
+		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
+		break;
+	case TTY_LED_RNG:
+		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
+		break;
+	case TTY_LED_CNT:
+	default:
+		ret = tty_get_icount(trigger_data->tty, &icount);
+		if (ret) {
+			dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
+			mutex_unlock(&trigger_data->mutex);
+			return;
+		}
+
+		if (icount.rx != trigger_data->rx ||
+		    icount.tx != trigger_data->tx) {
+			led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
+
+			trigger_data->rx = icount.rx;
+			trigger_data->tx = icount.tx;
+		} else {
+			led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
+		}
+		break;
 	}
 
 out:
@@ -137,6 +248,7 @@ static void ledtrig_tty_work(struct work_struct *work)
 
 static struct attribute *ledtrig_tty_attrs[] = {
 	&dev_attr_ttyname.attr,
+	&dev_attr_tty_led_mode.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(ledtrig_tty);
@@ -149,6 +261,9 @@ static int ledtrig_tty_activate(struct led_classdev *led_cdev)
 	if (!trigger_data)
 		return -ENOMEM;
 
+	/* set default mode */
+	trigger_data->mode = TTY_LED_CNT;
+
 	led_set_trigger_data(led_cdev, trigger_data);
 
 	INIT_DELAYED_WORK(&trigger_data->dwork, ledtrig_tty_work);
-- 
2.30.2

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Lee Jones]

On Wed, 22 Feb 2023, Florian Eckert wrote:

> Add additional modes to trigger the selected LED.
> The following modes are supported:
> 
> Tx/Rx:	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 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>
> ---
>  .../ABI/testing/sysfs-class-led-trigger-tty   |  17 ++
>  drivers/leds/trigger/ledtrig-tty.c            | 145 ++++++++++++++++--
>  2 files changed, 147 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-tty b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
> index 2bf6b24e781b..1c28e6c61d19 100644
> --- a/Documentation/ABI/testing/sysfs-class-led-trigger-tty
> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
> @@ -4,3 +4,20 @@ KernelVersion:	5.10
>  Contact:	linux-leds@vger.kernel.org
>  Description:
>  		Specifies the tty device name of the triggering tty
> +
> +What:		/sys/class/leds/<led>/mode
> +Date:		January 2023
> +KernelVersion:	6.3
> +Description:
> +		Specifies the operating to trigger the LED.

The operating ... ?  "mode"?

> +		The following operating modes are supported:
> +
> +		* Tx/Rx: Flash LED on data transmission (default)
> +		* CTS:   DCE Ready to accept data from the DTE.
> +		  LED on if line is high.
> +		* DSR:   DCE is ready to receive and send data.
> +		  LED on if line is high.
> +		* CAR:   DCE has detected a carrier from a remote DTE.
> +		  LED on if line is high.
> +		* RNG:   DCE has detected an incoming ring signal.
> +		  LED on if line is high.

Seeing as this is unchanging, how about you mention it once globally?

> diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
> index f62db7e520b5..7c4c171c8745 100644
> --- a/drivers/leds/trigger/ledtrig-tty.c
> +++ b/drivers/leds/trigger/ledtrig-tty.c
> @@ -7,6 +7,15 @@
>  #include <linux/tty.h>
>  #include <uapi/linux/serial.h>
>  
> +enum tty_led_mode {
> +	TTY_LED_CNT,

What's CNT?  Is it documented somewhere else?  Ah, I see below that this
is Tx/Rx.  Odd name, what does it mean?  Defines and Enums should be
self documenting IMHO.

> +	TTY_LED_CTS,
> +	TTY_LED_DSR,
> +	TTY_LED_CAR,
> +	TTY_LED_RNG,
> +	__TTY_LED_LAST = TTY_LED_RNG

Do you have to prepend with _'s?

> +};
> +
>  struct ledtrig_tty_data {
>  	struct led_classdev *led_cdev;
>  	struct delayed_work dwork;
> @@ -14,6 +23,15 @@ struct ledtrig_tty_data {
>  	const char *ttyname;
>  	struct tty_struct *tty;
>  	int rx, tx;
> +	enum tty_led_mode mode;
> +};
> +
> +static const char * const mode[] = {
> +	[TTY_LED_CNT] = "Tx/Rx", // Trasmit Data / Receive Data

C++ style comments?

> +	[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 +39,70 @@ static void ledtrig_tty_restart(struct ledtrig_tty_data *trigger_data)
>  	schedule_delayed_work(&trigger_data->dwork, 0);
>  }
>  
> +static ssize_t ledtrig_tty_mode_show(char *buf, enum tty_led_mode tty_mode)
> +{
> +	int len = 0;
> +	int i;
> +
> +	for (i = 0; i <= __TTY_LED_LAST; i++) {
> +		bool hit = tty_mode == i;
> +		bool last = i == __TTY_LED_LAST;
> +
> +		len += sysfs_emit_at(buf, len, "%s%s%s%s",
> +				  hit ? "[" : "",
> +				  mode[i],
> +				  hit ? "]" : "",
> +				  last ? "" : " ");
> +	}
> +
> +	len += sysfs_emit_at(buf, len, "\n");
> +
> +	return len;
> +}
> +
> +static ssize_t tty_led_mode_show(struct device *dev,
> +			 struct device_attribute *attr, char *buf)

This may be a personal preference, but I'd rather see alignment with the '('.

> +{
> +	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);
> +
> +	return ledtrig_tty_mode_show(buf, tty_mode);
> +}
> +
> +static ssize_t tty_led_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 = __TTY_LED_LAST;

Nit: Can you reverse these 2 lines to make my OCD happy please?

> +	int i;
> +
> +	/* Check for new line in string*/

' ' before the '*'.

> +	if (size > 0 && buf[size - 1] == '\n')
> +		size -= 1;
> +
> +	for (i = 0; i <= __TTY_LED_LAST; i++)
> +		if (strncmp(buf, mode[i], size) == 0) {
> +			tty_mode = i;
> +			break;
> +		}
> +
> +	if (i > __TTY_LED_LAST)
> +		return -EINVAL;
> +
> +	mutex_lock(&trigger_data->mutex);
> +	trigger_data->mode = tty_mode;
> +	mutex_unlock(&trigger_data->mutex);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RW(tty_led_mode);
> +
>  static ssize_t ttyname_show(struct device *dev,
>  			    struct device_attribute *attr, char *buf)
>  {
> @@ -76,6 +158,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)

This can be on a single line.  Please use 100-chars throughout.

> +{
> +	unsigned int status;
> +
> +	status = tty_get_mget(trigger_data->tty);
> +	if (status & flag)
> +		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> +	else
> +		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> +}
> +
>  static void ledtrig_tty_work(struct work_struct *work)
>  {
>  	struct ledtrig_tty_data *trigger_data =
> @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
>  		trigger_data->tty = tty;
>  	}
>  
> -	ret = tty_get_icount(trigger_data->tty, &icount);
> -	if (ret) {
> -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
> -		mutex_unlock(&trigger_data->mutex);
> -		return;
> -	}
> -
> -	if (icount.rx != trigger_data->rx ||
> -	    icount.tx != trigger_data->tx) {
> -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> -
> -		trigger_data->rx = icount.rx;
> -		trigger_data->tx = icount.tx;
> -	} else {
> -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> +	switch (trigger_data->mode) {
> +	case TTY_LED_CTS:
> +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
> +		break;
> +	case TTY_LED_DSR:
> +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
> +		break;
> +	case TTY_LED_CAR:
> +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
> +		break;
> +	case TTY_LED_RNG:
> +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
> +		break;
> +	case TTY_LED_CNT:

I believe this requires a 'fall-through' statement.

Documentation/process/deprecated.rst

> +	default:
> +		ret = tty_get_icount(trigger_data->tty, &icount);
> +		if (ret) {
> +			dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
> +			mutex_unlock(&trigger_data->mutex);
> +			return;
> +		}
> +
> +		if (icount.rx != trigger_data->rx ||
> +		    icount.tx != trigger_data->tx) {

One line, etc.

> +			led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> +
> +			trigger_data->rx = icount.rx;
> +			trigger_data->tx = icount.tx;
> +		} else {
> +			led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> +		}
> +		break;
>  	}
>  
>  out:
> @@ -137,6 +248,7 @@ static void ledtrig_tty_work(struct work_struct *work)
>  
>  static struct attribute *ledtrig_tty_attrs[] = {
>  	&dev_attr_ttyname.attr,
> +	&dev_attr_tty_led_mode.attr,
>  	NULL
>  };
>  ATTRIBUTE_GROUPS(ledtrig_tty);
> @@ -149,6 +261,9 @@ static int ledtrig_tty_activate(struct led_classdev *led_cdev)
>  	if (!trigger_data)
>  		return -ENOMEM;
>  
> +	/* set default mode */

Nit: "Set"

> +	trigger_data->mode = TTY_LED_CNT;
> +
>  	led_set_trigger_data(led_cdev, trigger_data);
>  
>  	INIT_DELAYED_WORK(&trigger_data->dwork, ledtrig_tty_work);
> -- 
> 2.30.2
> 

-- 
Lee Jones [李琼斯]

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Jiri Slaby]

On 03. 03. 23, 15:11, Lee Jones wrote:
> On Wed, 22 Feb 2023, Florian Eckert wrote:
>> @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
>>   		trigger_data->tty = tty;
>>   	}
>>   
>> -	ret = tty_get_icount(trigger_data->tty, &icount);
>> -	if (ret) {
>> -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
>> -		mutex_unlock(&trigger_data->mutex);
>> -		return;
>> -	}
>> -
>> -	if (icount.rx != trigger_data->rx ||
>> -	    icount.tx != trigger_data->tx) {
>> -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
>> -
>> -		trigger_data->rx = icount.rx;
>> -		trigger_data->tx = icount.tx;
>> -	} else {
>> -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
>> +	switch (trigger_data->mode) {
>> +	case TTY_LED_CTS:
>> +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
>> +		break;
>> +	case TTY_LED_DSR:
>> +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
>> +		break;
>> +	case TTY_LED_CAR:
>> +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
>> +		break;
>> +	case TTY_LED_RNG:
>> +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
>> +		break;
>> +	case TTY_LED_CNT:
> 
> I believe this requires a 'fall-through' statement.

I don't think this is the case. Isn't fallthrough required only in cases 
when there is at least one statement, i.e. a block?

> Documentation/process/deprecated.rst
> 
>> +	default:
>> +		ret = tty_get_icount(trigger_data->tty, &icount);
>> +		if (ret) {
>> +			dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
>> +			mutex_unlock(&trigger_data->mutex);
>> +			return;
>> +		}
>> +


-- 
js

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Florian Eckert]

On 2023-03-06 07:57, Jiri Slaby wrote:
> On 03. 03. 23, 15:11, Lee Jones wrote:
>> On Wed, 22 Feb 2023, Florian Eckert wrote:
>>> @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct 
>>> *work)
>>>   		trigger_data->tty = tty;
>>>   	}
>>>   -	ret = tty_get_icount(trigger_data->tty, &icount);
>>> -	if (ret) {
>>> -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped 
>>> polling\n");
>>> -		mutex_unlock(&trigger_data->mutex);
>>> -		return;
>>> -	}
>>> -
>>> -	if (icount.rx != trigger_data->rx ||
>>> -	    icount.tx != trigger_data->tx) {
>>> -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
>>> -
>>> -		trigger_data->rx = icount.rx;
>>> -		trigger_data->tx = icount.tx;
>>> -	} else {
>>> -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
>>> +	switch (trigger_data->mode) {
>>> +	case TTY_LED_CTS:
>>> +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
>>> +		break;
>>> +	case TTY_LED_DSR:
>>> +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
>>> +		break;
>>> +	case TTY_LED_CAR:
>>> +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
>>> +		break;
>>> +	case TTY_LED_RNG:
>>> +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
>>> +		break;
>>> +	case TTY_LED_CNT:
>> 
>> I believe this requires a 'fall-through' statement.
> 
> I don't think this is the case. Isn't fallthrough required only in
> cases when there is at least one statement, i.e. a block?

Jiri thanks for the advice

I also understood that I only need the /* Fall through */ comment if I 
also have at least one statement.
Which is not the case there. So I would say that fits.

For all other things, I am in the process of fixing that and sending a 
v8 patchset.

> 
>> Documentation/process/deprecated.rst
>> 
>>> +	default:
>>> +		ret = tty_get_icount(trigger_data->tty, &icount);
>>> +		if (ret) {
>>> +			dev_info(trigger_data->tty->dev, "Failed to get icount, stopped 
>>> polling\n");
>>> +			mutex_unlock(&trigger_data->mutex);
>>> +			return;
>>> +		}
>>> +

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Lee Jones]

On Mon, 06 Mar 2023, Jiri Slaby wrote:

> On 03. 03. 23, 15:11, Lee Jones wrote:
> > On Wed, 22 Feb 2023, Florian Eckert wrote:
> > > @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
> > >   		trigger_data->tty = tty;
> > >   	}
> > > -	ret = tty_get_icount(trigger_data->tty, &icount);
> > > -	if (ret) {
> > > -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
> > > -		mutex_unlock(&trigger_data->mutex);
> > > -		return;
> > > -	}
> > > -
> > > -	if (icount.rx != trigger_data->rx ||
> > > -	    icount.tx != trigger_data->tx) {
> > > -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> > > -
> > > -		trigger_data->rx = icount.rx;
> > > -		trigger_data->tx = icount.tx;
> > > -	} else {
> > > -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> > > +	switch (trigger_data->mode) {
> > > +	case TTY_LED_CTS:
> > > +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
> > > +		break;
> > > +	case TTY_LED_DSR:
> > > +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
> > > +		break;
> > > +	case TTY_LED_CAR:
> > > +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
> > > +		break;
> > > +	case TTY_LED_RNG:
> > > +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
> > > +		break;
> > > +	case TTY_LED_CNT:
> > 
> > I believe this requires a 'fall-through' statement.
> 
> I don't think this is the case. Isn't fallthrough required only in cases
> when there is at least one statement, i.e. a block?

There's no mention of this caveat in the document.

To my untrained eyes, the rule looks fairly explicit, starting with "All".

"
  All switch/case blocks must end in one of:

  * break;
  * fallthrough;
  * continue;
  * goto <label>;
  * return [expression];
"

If you're aware of something I'm not, please consider updating the doc.

> > Documentation/process/deprecated.rst
> > 
> > > +	default:
> > > +		ret = tty_get_icount(trigger_data->tty, &icount);
> > > +		if (ret) {
> > > +			dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
> > > +			mutex_unlock(&trigger_data->mutex);
> > > +			return;
> > > +		}
> > > +

-- 
Lee Jones [李琼斯]

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

On Mon, Mar 06, 2023 at 09:04:56AM +0000, Lee Jones wrote:
> On Mon, 06 Mar 2023, Jiri Slaby wrote:
> 
> > On 03. 03. 23, 15:11, Lee Jones wrote:
> > > On Wed, 22 Feb 2023, Florian Eckert wrote:
> > > > @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
> > > >   		trigger_data->tty = tty;
> > > >   	}
> > > > -	ret = tty_get_icount(trigger_data->tty, &icount);
> > > > -	if (ret) {
> > > > -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
> > > > -		mutex_unlock(&trigger_data->mutex);
> > > > -		return;
> > > > -	}
> > > > -
> > > > -	if (icount.rx != trigger_data->rx ||
> > > > -	    icount.tx != trigger_data->tx) {
> > > > -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> > > > -
> > > > -		trigger_data->rx = icount.rx;
> > > > -		trigger_data->tx = icount.tx;
> > > > -	} else {
> > > > -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> > > > +	switch (trigger_data->mode) {
> > > > +	case TTY_LED_CTS:
> > > > +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
> > > > +		break;
> > > > +	case TTY_LED_DSR:
> > > > +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
> > > > +		break;
> > > > +	case TTY_LED_CAR:
> > > > +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
> > > > +		break;
> > > > +	case TTY_LED_RNG:
> > > > +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
> > > > +		break;
> > > > +	case TTY_LED_CNT:
> > > 
> > > I believe this requires a 'fall-through' statement.
> > 
> > I don't think this is the case. Isn't fallthrough required only in cases
> > when there is at least one statement, i.e. a block?
> 
> There's no mention of this caveat in the document.
> 
> To my untrained eyes, the rule looks fairly explicit, starting with "All".
> 
> "
>   All switch/case blocks must end in one of:
> 
>   * break;
>   * fallthrough;
>   * continue;
>   * goto <label>;
>   * return [expression];
> "
> 
> If you're aware of something I'm not, please consider updating the doc.

Just to add my 0.02€: I think this case (i.e.

	case TTY_LED_CNT:
	default:
		...

) doesn't need a fall-through for two reasons:

 a) The compilers don't warn about this construct even with the
    fall-through warning enabled; and
 b) I wouldn't call the TTY_LED_CNT line a "block", so the quoted
    document[1] doesn't apply. (Though I agree that there is some
    potential for improvement by mentioning this case. (haha))

Best regards
Uwe

[1] Documentation/process/deprecated.rst

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Jiri Slaby]

On 06. 03. 23, 10:04, Lee Jones wrote:
> On Mon, 06 Mar 2023, Jiri Slaby wrote:
> 
>> On 03. 03. 23, 15:11, Lee Jones wrote:
>>> On Wed, 22 Feb 2023, Florian Eckert wrote:
>>>> @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
>>>>    		trigger_data->tty = tty;
>>>>    	}
>>>> -	ret = tty_get_icount(trigger_data->tty, &icount);
>>>> -	if (ret) {
>>>> -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
>>>> -		mutex_unlock(&trigger_data->mutex);
>>>> -		return;
>>>> -	}
>>>> -
>>>> -	if (icount.rx != trigger_data->rx ||
>>>> -	    icount.tx != trigger_data->tx) {
>>>> -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
>>>> -
>>>> -		trigger_data->rx = icount.rx;
>>>> -		trigger_data->tx = icount.tx;
>>>> -	} else {
>>>> -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
>>>> +	switch (trigger_data->mode) {
>>>> +	case TTY_LED_CTS:
>>>> +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
>>>> +		break;
>>>> +	case TTY_LED_DSR:
>>>> +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
>>>> +		break;
>>>> +	case TTY_LED_CAR:
>>>> +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
>>>> +		break;
>>>> +	case TTY_LED_RNG:
>>>> +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
>>>> +		break;
>>>> +	case TTY_LED_CNT:
>>>
>>> I believe this requires a 'fall-through' statement.
>>
>> I don't think this is the case. Isn't fallthrough required only in cases
>> when there is at least one statement, i.e. a block?
> 
> There's no mention of this caveat in the document.
> 
> To my untrained eyes, the rule looks fairly explicit, starting with "All".
> 
> "
>    All switch/case blocks must end in one of:
> 
>    * break;
>    * fallthrough;
>    * continue;
>    * goto <label>;
>    * return [expression];
> "
> 
> If you're aware of something I'm not, please consider updating the doc.

The magic word in the above is "block", IMO. A block is defined for me 
as a list of declarations and/or statements. Which is not the case in 
the above (i.e. in sequential "case"s).

Furthermore, the gcc docs specifically say about fallthrough attribute:
It can only be used in a switch statement (the compiler will issue an 
error otherwise), after a preceding statement and before a logically 
succeeding case label, or user-defined label.

While "case X:" is technically a (label) statement, I don't think they 
were thinking of it as such here due to following "succeeding case 
label" in the text.

So checking with the code, gcc indeed skips those 
(should_warn_for_implicit_fallthrough()):
   /* Skip all immediately following labels.  */
   while (!gsi_end_p (gsi)
          && (gimple_code (gsi_stmt (gsi)) == GIMPLE_LABEL
              || gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT))
     gsi_next_nondebug (&gsi);


Apart from that, fallthrough only makes the code harder to read:

case X:
case Y:
case Z:
default:
   do_something();

VS

case X:
   fallthrough;
case Y:
   fallthrough;
case Z:
   fallthrough;
default:
   do_something();

The first one is a clear win, IMO, and it's pretty clear that it falls 
through on purpose. And even for compiler -- it shall not produce a 
warning in that case.

regards,
-- 
js
suse labs

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Lee Jones]

On Mon, 06 Mar 2023, Jiri Slaby wrote:

> On 06. 03. 23, 10:04, Lee Jones wrote:
> > On Mon, 06 Mar 2023, Jiri Slaby wrote:
> > 
> > > On 03. 03. 23, 15:11, Lee Jones wrote:
> > > > On Wed, 22 Feb 2023, Florian Eckert wrote:
> > > > > @@ -113,21 +207,38 @@ static void ledtrig_tty_work(struct work_struct *work)
> > > > >    		trigger_data->tty = tty;
> > > > >    	}
> > > > > -	ret = tty_get_icount(trigger_data->tty, &icount);
> > > > > -	if (ret) {
> > > > > -		dev_info(trigger_data->tty->dev, "Failed to get icount, stopped polling\n");
> > > > > -		mutex_unlock(&trigger_data->mutex);
> > > > > -		return;
> > > > > -	}
> > > > > -
> > > > > -	if (icount.rx != trigger_data->rx ||
> > > > > -	    icount.tx != trigger_data->tx) {
> > > > > -		led_set_brightness_sync(trigger_data->led_cdev, LED_ON);
> > > > > -
> > > > > -		trigger_data->rx = icount.rx;
> > > > > -		trigger_data->tx = icount.tx;
> > > > > -	} else {
> > > > > -		led_set_brightness_sync(trigger_data->led_cdev, LED_OFF);
> > > > > +	switch (trigger_data->mode) {
> > > > > +	case TTY_LED_CTS:
> > > > > +		ledtrig_tty_flags(trigger_data, TIOCM_CTS);
> > > > > +		break;
> > > > > +	case TTY_LED_DSR:
> > > > > +		ledtrig_tty_flags(trigger_data, TIOCM_DSR);
> > > > > +		break;
> > > > > +	case TTY_LED_CAR:
> > > > > +		ledtrig_tty_flags(trigger_data, TIOCM_CAR);
> > > > > +		break;
> > > > > +	case TTY_LED_RNG:
> > > > > +		ledtrig_tty_flags(trigger_data, TIOCM_RNG);
> > > > > +		break;
> > > > > +	case TTY_LED_CNT:
> > > > 
> > > > I believe this requires a 'fall-through' statement.
> > > 
> > > I don't think this is the case. Isn't fallthrough required only in cases
> > > when there is at least one statement, i.e. a block?
> > 
> > There's no mention of this caveat in the document.
> > 
> > To my untrained eyes, the rule looks fairly explicit, starting with "All".
> > 
> > "
> >    All switch/case blocks must end in one of:
> > 
> >    * break;
> >    * fallthrough;
> >    * continue;
> >    * goto <label>;
> >    * return [expression];
> > "
> > 
> > If you're aware of something I'm not, please consider updating the doc.
> 
> The magic word in the above is "block", IMO. A block is defined for me as a
> list of declarations and/or statements. Which is not the case in the above
> (i.e. in sequential "case"s).
> 
> Furthermore, the gcc docs specifically say about fallthrough attribute:
> It can only be used in a switch statement (the compiler will issue an error
> otherwise), after a preceding statement and before a logically succeeding
> case label, or user-defined label.
> 
> While "case X:" is technically a (label) statement, I don't think they were
> thinking of it as such here due to following "succeeding case label" in the
> text.
> 
> So checking with the code, gcc indeed skips those
> (should_warn_for_implicit_fallthrough()):
>   /* Skip all immediately following labels.  */
>   while (!gsi_end_p (gsi)
>          && (gimple_code (gsi_stmt (gsi)) == GIMPLE_LABEL
>              || gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT))
>     gsi_next_nondebug (&gsi);
> 
> 
> Apart from that, fallthrough only makes the code harder to read:
> 
> case X:
> case Y:
> case Z:
> default:
>   do_something();
> 
> VS
> 
> case X:
>   fallthrough;
> case Y:
>   fallthrough;
> case Z:
>   fallthrough;
> default:
>   do_something();
> 
> The first one is a clear win, IMO, and it's pretty clear that it falls
> through on purpose. And even for compiler -- it shall not produce a warning
> in that case.

Works for me.  Thanks for the clear explanation, Jiri and Uwe.

And yes Uwe, it would be good if we could make that clearer in the doc.

-- 
Lee Jones [李琼斯]

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

On Wed, Feb 22, 2023 at 09:33:35AM +0100, Florian Eckert wrote:
> Add additional modes to trigger the selected LED.
> The following modes are supported:
> 
> Tx/Rx:	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 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>
> ---
>  .../ABI/testing/sysfs-class-led-trigger-tty   |  17 ++
>  drivers/leds/trigger/ledtrig-tty.c            | 145 ++++++++++++++++--
>  2 files changed, 147 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-tty b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
> index 2bf6b24e781b..1c28e6c61d19 100644
> --- a/Documentation/ABI/testing/sysfs-class-led-trigger-tty
> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
> @@ -4,3 +4,20 @@ KernelVersion:	5.10
>  Contact:	linux-leds@vger.kernel.org
>  Description:
>  		Specifies the tty device name of the triggering tty
> +
> +What:		/sys/class/leds/<led>/mode
> +Date:		January 2023
> +KernelVersion:	6.3
> +Description:
> +		Specifies the operating to trigger the LED.
> +		The following operating modes are supported:
> +
> +		* Tx/Rx: Flash LED on data transmission (default)
> +		* CTS:   DCE Ready to accept data from the DTE.
> +		  LED on if line is high.
> +		* DSR:   DCE is ready to receive and send data.
> +		  LED on if line is high.
> +		* CAR:   DCE has detected a carrier from a remote DTE.
> +		  LED on if line is high.
> +		* RNG:   DCE has detected an incoming ring signal.
> +		  LED on if line is high.

Something I (still) don't like about this approach is that you cannot
make the LED flash on TX only (or CAR and DSR). Something like:

	led=/sys/class/leds/<led>/
	echo 1 > $led/TX
	echo 0 > $led/RX
	echo 1 > $led/CAR

would be a more flexible and IMHO nicer interface. (Maybe with improved
file names.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v7 2/2] trigger: ledtrig-tty: add additional modes

[Florian Eckert]

Hello Uwe,

>> +		  LED on if line is high.
>> +		* RNG:   DCE has detected an incoming ring signal.
>> +		  LED on if line is high.
> 
> Something I (still) don't like about this approach is that you cannot
> make the LED flash on TX only (or CAR and DSR). Something like:
> 
> 	led=/sys/class/leds/<led>/
> 	echo 1 > $led/TX
> 	echo 0 > $led/RX
> 	echo 1 > $led/CAR
> 
> would be a more flexible and IMHO nicer interface. (Maybe with improved
> file names.)

The question is whether it makes sense to combine several states on one
LED. We can add TTY_LED_RX or TTY_LED_TX to meet your requirements.
The only led trigger I know that combines multiple states is 
ledtrig-netdev.

If so, I can only imagine that we handle it the same way as with
ledtrig-netdev. For the states CTS/DSR/CAR/RNG, the LED goes on or off
and when data is transmitted (rx/tx), the LED flashes.

I have personally have a usecase where I need to indicate whether
I am getting CTS from the mode or not.

If that's how we want to do it, then I can only imagine that:

led=/sys/class/leds/<led>/
  	echo 1 > $led/rx
  	echo 0 > $led/tx
  	echo <CTS|DSR|CAR|RNG> > $led/tty_led_mode

I think it only makes sense to always display only one mode

This are "CTS|DSR|CAR|RNG".


Personally, I think
it complicates things because the LED shows several states.

Best regards
Florian