[PATCH v2 0/4] ledtrig-tty: add new state evaluation

[PATCH v2 0/4] ledtrig-tty: add new state evaluation

[Florian Eckert]

Changes in v2:
- rename new function from tty_get_mget() to tty_get_tiocm() as
  requested by 'Jiri Slaby'.
- As suggested by 'Jiri Slaby', fixed tabs in function documentation
  throughout the file '/drivers/tty/tty_io.c' in a separate commit.
- Move the variable definition to the top in function 'ledtrig_tty_work()'.
  This was reported by the 'kernel test robot' after my change in v1.
- Also set the 'max_brightness' to 'blink_brightness' if no
  'blink_brightness' was set. This fixes a problem at startup when the
  brightness is still set to 0 and only 'line_*' is evaluated. I looked in
  the netdev trigger and that's exactly how it's done there.

v1:
This is a follow-up patchset, based on the mailing list discussion from
March 2023 based on the old patchset v7 [1]. I have changed, the LED trigger
handling via the sysfs interfaces as suggested by Uwe Kleine-König.

[1]
https://lore.kernel.org/linux-leds/20230306093524.amm7o4ppa7gon4ew@pengutronix.de/

Florian Eckert (4):
  tty: whitespaces in descriptions corrected by replacing tabs with
    spaces.
  tty: add new helper function tty_get_tiocm
  trigger: ledtrig-tty: move variable definition to the top
  trigger: ledtrig-tty: add new line mode to triggers

 .../ABI/testing/sysfs-class-led-trigger-tty   |  53 ++++
 drivers/leds/trigger/ledtrig-tty.c            | 280 +++++++++++++++++-
 drivers/tty/tty_io.c                          | 130 ++++----
 include/linux/tty.h                           |   1 +
 4 files changed, 396 insertions(+), 68 deletions(-)

-- 
2.30.2

[PATCH v2 1/4] tty: whitespaces in descriptions corrected by replacing tabs with spaces.

[Florian Eckert]

Tabs were used in the function description, to make this look more
uniform, the tabs were replaced by spaces where necessary.

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
 drivers/tty/tty_io.c | 102 +++++++++++++++++++++----------------------
 1 file changed, 51 insertions(+), 51 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 8a94e5a43c6d..3299a5d50727 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -159,7 +159,7 @@ static int tty_fasync(int fd, struct file *filp, int on);
 static void release_tty(struct tty_struct *tty, int idx);
 
 /**
- * free_tty_struct	-	free a disused tty
+ * free_tty_struct - free a disused tty
  * @tty: tty struct to free
  *
  * Free the write buffers, tty queue and tty memory itself.
@@ -233,7 +233,7 @@ static void tty_del_file(struct file *file)
 }
 
 /**
- * tty_name	-	return tty naming
+ * tty_name - return tty naming
  * @tty: tty structure
  *
  * Convert a tty structure into a name. The name reflects the kernel naming
@@ -295,7 +295,7 @@ static void check_tty_count(struct tty_struct *tty, const char *routine)
 }
 
 /**
- * get_tty_driver		-	find device of a tty
+ * get_tty_driver - find device of a tty
  * @device: device identifier
  * @index: returns the index of the tty
  *
@@ -320,7 +320,7 @@ static struct tty_driver *get_tty_driver(dev_t device, int *index)
 }
 
 /**
- * tty_dev_name_to_number	-	return dev_t for device name
+ * tty_dev_name_to_number - return dev_t for device name
  * @name: user space name of device under /dev
  * @number: pointer to dev_t that this function will populate
  *
@@ -372,7 +372,7 @@ EXPORT_SYMBOL_GPL(tty_dev_name_to_number);
 #ifdef CONFIG_CONSOLE_POLL
 
 /**
- * tty_find_polling_driver	-	find device of a polled tty
+ * tty_find_polling_driver - find device of a polled tty
  * @name: name string to match
  * @line: pointer to resulting tty line nr
  *
@@ -505,7 +505,7 @@ static DEFINE_SPINLOCK(redirect_lock);
 static struct file *redirect;
 
 /**
- * tty_wakeup	-	request more data
+ * tty_wakeup - request more data
  * @tty: terminal
  *
  * Internal and external helper for wakeups of tty. This function informs the
@@ -529,7 +529,7 @@ void tty_wakeup(struct tty_struct *tty)
 EXPORT_SYMBOL_GPL(tty_wakeup);
 
 /**
- * tty_release_redirect	-	Release a redirect on a pty if present
+ * tty_release_redirect - Release a redirect on a pty if present
  * @tty: tty device
  *
  * This is available to the pty code so if the master closes, if the slave is a
@@ -550,7 +550,7 @@ static struct file *tty_release_redirect(struct tty_struct *tty)
 }
 
 /**
- * __tty_hangup		-	actual handler for hangup events
+ * __tty_hangup - actual handler for hangup events
  * @tty: tty device
  * @exit_session: if non-zero, signal all foreground group processes
  *
@@ -673,7 +673,7 @@ static void do_tty_hangup(struct work_struct *work)
 }
 
 /**
- * tty_hangup		-	trigger a hangup event
+ * tty_hangup - trigger a hangup event
  * @tty: tty to hangup
  *
  * A carrier loss (virtual or otherwise) has occurred on @tty. Schedule a
@@ -687,7 +687,7 @@ void tty_hangup(struct tty_struct *tty)
 EXPORT_SYMBOL(tty_hangup);
 
 /**
- * tty_vhangup		-	process vhangup
+ * tty_vhangup - process vhangup
  * @tty: tty to hangup
  *
  * The user has asked via system call for the terminal to be hung up. We do
@@ -703,7 +703,7 @@ EXPORT_SYMBOL(tty_vhangup);
 
 
 /**
- * tty_vhangup_self	-	process vhangup for own ctty
+ * tty_vhangup_self - process vhangup for own ctty
  *
  * Perform a vhangup on the current controlling tty
  */
@@ -719,7 +719,7 @@ void tty_vhangup_self(void)
 }
 
 /**
- * tty_vhangup_session	-	hangup session leader exit
+ * tty_vhangup_session - hangup session leader exit
  * @tty: tty to hangup
  *
  * The session leader is exiting and hanging up its controlling terminal.
@@ -735,7 +735,7 @@ void tty_vhangup_session(struct tty_struct *tty)
 }
 
 /**
- * tty_hung_up_p	-	was tty hung up
+ * tty_hung_up_p - was tty hung up
  * @filp: file pointer of tty
  *
  * Return: true if the tty has been subject to a vhangup or a carrier loss
@@ -756,7 +756,7 @@ void __stop_tty(struct tty_struct *tty)
 }
 
 /**
- * stop_tty	-	propagate flow control
+ * stop_tty - propagate flow control
  * @tty: tty to stop
  *
  * Perform flow control to the driver. May be called on an already stopped
@@ -790,7 +790,7 @@ void __start_tty(struct tty_struct *tty)
 }
 
 /**
- * start_tty	-	propagate flow control
+ * start_tty - propagate flow control
  * @tty: tty to start
  *
  * Start a tty that has been stopped if at all possible. If @tty was previously
@@ -898,7 +898,7 @@ static ssize_t iterate_tty_read(struct tty_ldisc *ld, struct tty_struct *tty,
 
 
 /**
- * tty_read	-	read method for tty device files
+ * tty_read - read method for tty device files
  * @iocb: kernel I/O control block
  * @to: destination for the data read
  *
@@ -1091,7 +1091,7 @@ static ssize_t file_tty_write(struct file *file, struct kiocb *iocb, struct iov_
 }
 
 /**
- * tty_write		-	write method for tty device file
+ * tty_write - write method for tty device file
  * @iocb: kernel I/O control block
  * @from: iov_iter with data to write
  *
@@ -1133,7 +1133,7 @@ ssize_t redirected_tty_write(struct kiocb *iocb, struct iov_iter *iter)
 }
 
 /**
- * tty_send_xchar	-	send priority character
+ * tty_send_xchar - send priority character
  * @tty: the tty to send to
  * @ch: xchar to send
  *
@@ -1167,7 +1167,7 @@ int tty_send_xchar(struct tty_struct *tty, char ch)
 }
 
 /**
- * pty_line_name	-	generate name for a pty
+ * pty_line_name - generate name for a pty
  * @driver: the tty driver in use
  * @index: the minor number
  * @p: output buffer of at least 6 bytes
@@ -1188,7 +1188,7 @@ static void pty_line_name(struct tty_driver *driver, int index, char *p)
 }
 
 /**
- * tty_line_name	-	generate name for a tty
+ * tty_line_name - generate name for a tty
  * @driver: the tty driver in use
  * @index: the minor number
  * @p: output buffer of at least 7 bytes
@@ -1239,7 +1239,7 @@ static struct tty_struct *tty_driver_lookup_tty(struct tty_driver *driver,
 }
 
 /**
- * tty_init_termios	-  helper for termios setup
+ * tty_init_termios - helper for termios setup
  * @tty: the tty to set up
  *
  * Initialise the termios structure for this tty. This runs under the
@@ -1322,7 +1322,7 @@ static void tty_driver_remove_tty(struct tty_driver *driver, struct tty_struct *
 }
 
 /**
- * tty_reopen()	- fast re-open of an open tty
+ * tty_reopen() - fast re-open of an open tty
  * @tty: the tty to open
  *
  * Re-opens on master ptys are not allowed and return -%EIO.
@@ -1366,7 +1366,7 @@ static int tty_reopen(struct tty_struct *tty)
 }
 
 /**
- * tty_init_dev		-	initialise a tty device
+ * tty_init_dev - initialise a tty device
  * @driver: tty driver we are opening a device on
  * @idx: device index
  *
@@ -1488,7 +1488,7 @@ void tty_save_termios(struct tty_struct *tty)
 EXPORT_SYMBOL_GPL(tty_save_termios);
 
 /**
- * tty_flush_works	-	flush all works of a tty/pty pair
+ * tty_flush_works - flush all works of a tty/pty pair
  * @tty: tty device to flush works for (or either end of a pty pair)
  *
  * Sync flush all works belonging to @tty (and the 'other' tty).
@@ -1504,7 +1504,7 @@ static void tty_flush_works(struct tty_struct *tty)
 }
 
 /**
- * release_one_tty	-	release tty structure memory
+ * release_one_tty - release tty structure memory
  * @work: work of tty we are obliterating
  *
  * Releases memory associated with a tty structure, and clears out the
@@ -1552,7 +1552,7 @@ static void queue_release_one_tty(struct kref *kref)
 }
 
 /**
- * tty_kref_put		-	release a tty kref
+ * tty_kref_put - release a tty kref
  * @tty: tty device
  *
  * Release a reference to the @tty device and if need be let the kref layer
@@ -1566,7 +1566,7 @@ void tty_kref_put(struct tty_struct *tty)
 EXPORT_SYMBOL(tty_kref_put);
 
 /**
- * release_tty		-	release tty structure memory
+ * release_tty - release tty structure memory
  * @tty: tty device release
  * @idx: index of the tty device release
  *
@@ -1643,7 +1643,7 @@ static int tty_release_checks(struct tty_struct *tty, int idx)
 }
 
 /**
- * tty_kclose      -       closes tty opened by tty_kopen
+ * tty_kclose - closes tty opened by tty_kopen
  * @tty: tty device
  *
  * Performs the final steps to release and free a tty device. It is the same as
@@ -1673,7 +1673,7 @@ void tty_kclose(struct tty_struct *tty)
 EXPORT_SYMBOL_GPL(tty_kclose);
 
 /**
- * tty_release_struct	-	release a tty struct
+ * tty_release_struct - release a tty struct
  * @tty: tty device
  * @idx: index of the tty
  *
@@ -1702,7 +1702,7 @@ void tty_release_struct(struct tty_struct *tty, int idx)
 EXPORT_SYMBOL_GPL(tty_release_struct);
 
 /**
- * tty_release		-	vfs callback for close
+ * tty_release - vfs callback for close
  * @inode: inode of tty
  * @filp: file pointer for handle to tty
  *
@@ -1983,7 +1983,7 @@ static struct tty_struct *tty_kopen(dev_t device, int shared)
 }
 
 /**
- * tty_kopen_exclusive	-	open a tty device for kernel
+ * tty_kopen_exclusive - open a tty device for kernel
  * @device: dev_t of device to open
  *
  * Opens tty exclusively for kernel. Performs the driver lookup, makes sure
@@ -2003,7 +2003,7 @@ struct tty_struct *tty_kopen_exclusive(dev_t device)
 EXPORT_SYMBOL_GPL(tty_kopen_exclusive);
 
 /**
- * tty_kopen_shared	-	open a tty device for shared in-kernel use
+ * tty_kopen_shared - open a tty device for shared in-kernel use
  * @device: dev_t of device to open
  *
  * Opens an already existing tty for in-kernel use. Compared to
@@ -2018,7 +2018,7 @@ struct tty_struct *tty_kopen_shared(dev_t device)
 EXPORT_SYMBOL_GPL(tty_kopen_shared);
 
 /**
- * tty_open_by_driver	-	open a tty device
+ * tty_open_by_driver - open a tty device
  * @device: dev_t of device to open
  * @filp: file pointer to tty
  *
@@ -2086,7 +2086,7 @@ static struct tty_struct *tty_open_by_driver(dev_t device,
 }
 
 /**
- * tty_open	-	open a tty device
+ * tty_open - open a tty device
  * @inode: inode of device file
  * @filp: file pointer to tty
  *
@@ -2180,7 +2180,7 @@ static int tty_open(struct inode *inode, struct file *filp)
 
 
 /**
- * tty_poll	-	check tty status
+ * tty_poll - check tty status
  * @filp: file being polled
  * @wait: poll wait structures to update
  *
@@ -2258,7 +2258,7 @@ static int tty_fasync(int fd, struct file *filp, int on)
 
 static bool tty_legacy_tiocsti __read_mostly = IS_ENABLED(CONFIG_LEGACY_TIOCSTI);
 /**
- * tiocsti		-	fake input character
+ * tiocsti - fake input character
  * @tty: tty to fake input into
  * @p: pointer to character
  *
@@ -2295,7 +2295,7 @@ static int tiocsti(struct tty_struct *tty, char __user *p)
 }
 
 /**
- * tiocgwinsz		-	implement window query ioctl
+ * tiocgwinsz - implement window query ioctl
  * @tty: tty
  * @arg: user buffer for result
  *
@@ -2316,7 +2316,7 @@ static int tiocgwinsz(struct tty_struct *tty, struct winsize __user *arg)
 }
 
 /**
- * tty_do_resize	-	resize event
+ * tty_do_resize - resize event
  * @tty: tty being resized
  * @ws: new dimensions
  *
@@ -2346,7 +2346,7 @@ int tty_do_resize(struct tty_struct *tty, struct winsize *ws)
 EXPORT_SYMBOL(tty_do_resize);
 
 /**
- * tiocswinsz		-	implement window size set ioctl
+ * tiocswinsz - implement window size set ioctl
  * @tty: tty side of tty
  * @arg: user buffer for result
  *
@@ -2373,7 +2373,7 @@ static int tiocswinsz(struct tty_struct *tty, struct winsize __user *arg)
 }
 
 /**
- * tioccons	-	allow admin to move logical console
+ * tioccons - allow admin to move logical console
  * @file: the file to become console
  *
  * Allow the administrator to move the redirected console device.
@@ -2412,7 +2412,7 @@ static int tioccons(struct file *file)
 }
 
 /**
- * tiocsetd	-	set line discipline
+ * tiocsetd - set line discipline
  * @tty: tty device
  * @p: pointer to user data
  *
@@ -2434,7 +2434,7 @@ static int tiocsetd(struct tty_struct *tty, int __user *p)
 }
 
 /**
- * tiocgetd	-	get line discipline
+ * tiocgetd - get line discipline
  * @tty: tty device
  * @p: pointer to user data
  *
@@ -2457,7 +2457,7 @@ static int tiocgetd(struct tty_struct *tty, int __user *p)
 }
 
 /**
- * send_break	-	performed time break
+ * send_break - performed time break
  * @tty: device to break on
  * @duration: timeout in mS
  *
@@ -2495,7 +2495,7 @@ static int send_break(struct tty_struct *tty, unsigned int duration)
 }
 
 /**
- * tty_tiocmget		-	get modem status
+ * tty_tiocmget - get modem status
  * @tty: tty device
  * @p: pointer to result
  *
@@ -2518,7 +2518,7 @@ static int tty_tiocmget(struct tty_struct *tty, int __user *p)
 }
 
 /**
- * tty_tiocmset		-	set modem status
+ * tty_tiocmset - set modem status
  * @tty: tty device
  * @cmd: command - clear bits, set bits or set all
  * @p: pointer to desired bits
@@ -2559,7 +2559,7 @@ static int tty_tiocmset(struct tty_struct *tty, unsigned int cmd,
 }
 
 /**
- * tty_get_icount	-	get tty statistics
+ * tty_get_icount - get tty statistics
  * @tty: tty device
  * @icount: output parameter
  *
@@ -3122,7 +3122,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver *driver, int idx)
 }
 
 /**
- * tty_put_char	- write one character to a tty
+ * tty_put_char - write one character to a tty
  * @tty: tty
  * @ch: character to write
  *
@@ -3300,7 +3300,7 @@ void tty_unregister_device(struct tty_driver *driver, unsigned index)
 EXPORT_SYMBOL(tty_unregister_device);
 
 /**
- * __tty_alloc_driver -- allocate tty driver
+ * __tty_alloc_driver - allocate tty driver
  * @lines: count of lines this driver can handle at most
  * @owner: module which is responsible for this driver
  * @flags: some of %TTY_DRIVER_ flags, will be set in driver->flags
@@ -3393,7 +3393,7 @@ static void destruct_tty_driver(struct kref *kref)
 }
 
 /**
- * tty_driver_kref_put -- drop a reference to a tty driver
+ * tty_driver_kref_put - drop a reference to a tty driver
  * @driver: driver of which to drop the reference
  *
  * The final put will destroy and free up the driver.
@@ -3405,7 +3405,7 @@ void tty_driver_kref_put(struct tty_driver *driver)
 EXPORT_SYMBOL(tty_driver_kref_put);
 
 /**
- * tty_register_driver -- register a tty driver
+ * tty_register_driver - register a tty driver
  * @driver: driver to register
  *
  * Called by a tty driver to register itself.
@@ -3470,7 +3470,7 @@ int tty_register_driver(struct tty_driver *driver)
 EXPORT_SYMBOL(tty_register_driver);
 
 /**
- * tty_unregister_driver -- unregister a tty driver
+ * tty_unregister_driver - unregister a tty driver
  * @driver: driver to unregister
  *
  * Called by a tty driver to unregister itself.
-- 
2.30.2

[PATCH v2 2/4] tty: add new helper function tty_get_tiocm

[Florian Eckert]

The struct 'tty_struct' has a callback to read the status flags of the tty
if the tty driver provides them. So fare, the data is transferred directly
to userspace with the function 'tty_tiocmget'. This function cannot be
used to evaluate the status line of the tty interface in the ledtrig-tty
trigger. To make this possible, a new function must be added that does
not immediately pass the data on to userspace.

The new function 'tty_get_tiocm' only returns the status register.
This information can then be processed further in the ledtrig-tty
trigger.

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 3299a5d50727..a12f63854ac4 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2494,6 +2494,24 @@ static int send_break(struct tty_struct *tty, unsigned int duration)
 	return retval;
 }
 
+/**
+ * tty_get_tiocm - get tiocm status register
+ * @tty: tty device
+ *
+ * Obtain the modem status bits from the tty driver if the feature
+ * is supported.
+ */
+int tty_get_tiocm(struct tty_struct *tty)
+{
+	int retval = -ENOTTY;
+
+	if (tty->ops->tiocmget)
+		retval = tty->ops->tiocmget(tty);
+
+	return retval;
+}
+EXPORT_SYMBOL_GPL(tty_get_tiocm);
+
 /**
  * tty_tiocmget - get modem status
  * @tty: tty device
@@ -2506,14 +2524,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_tiocm(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 f002d0f25db7..8e4d0b3b12b7 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_tiocm(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 v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Florian Eckert]

The Intel build robot has complained about this. Hence move the commit
of the variable definition to the beginning of the function.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
 drivers/leds/trigger/ledtrig-tty.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
index 8ae0d2d284af..1c6fadf0b856 100644
--- a/drivers/leds/trigger/ledtrig-tty.c
+++ b/drivers/leds/trigger/ledtrig-tty.c
@@ -82,6 +82,7 @@ static void ledtrig_tty_work(struct work_struct *work)
 {
 	struct ledtrig_tty_data *trigger_data =
 		container_of(work, struct ledtrig_tty_data, dwork.work);
+	unsigned long interval = LEDTRIG_TTY_INTERVAL;
 	struct serial_icounter_struct icount;
 	int ret;
 
@@ -124,8 +125,6 @@ static void ledtrig_tty_work(struct work_struct *work)
 
 	if (icount.rx != trigger_data->rx ||
 	    icount.tx != trigger_data->tx) {
-		unsigned long interval = LEDTRIG_TTY_INTERVAL;
-
 		led_blink_set_oneshot(trigger_data->led_cdev, &interval,
 				      &interval, 0);
 
-- 
2.30.2

[PATCH v2 4/4] trigger: ledtrig-tty: add new line mode to triggers

[Florian Eckert]

Until now, the LED blinks when data is sent via the tty (rx/tx).
The serial tty interface also supports additional input signals, that can
also be evaluated within this trigger. This change is adding the following
additional input sources, which could be controlled
via the '/sys/class/<leds>/' sysfs interface.

- line_cts:
  DCE is ready to accept data from the DTE (Clear To  Send). If the line
  state is detected, the LED is switched on.
  If set to 0 (default), the LED will not evaluate CTS.
  If set to 1, the LED will evaluate CTS.

- line_dsr:
  DCE is ready to receive and send data (Data Set Ready). If the line state
  is detected, the LED is switched on.
  If set to 0 (default), the LED will not evaluate DSR.
  If set to 1, the LED will evaluate DSR.

- line_car:
  DTE is receiving a carrier from the DCE (Data Carrier Detect). If the
  line state is detected, the LED is switched on.
  If set to 0 (default), the LED will not evaluate CAR (DCD).
  If set to 1, the LED will evaluate CAR (DCD).

- line_rng:
  DCE has detected an incoming ring signal on the telephone line
  (Ring Indicator). If the line state is detected, the LED is switched on.
  If set to 0 (default), the LED will not evaluate RNG (RI).
  If set to 1, the LED will evaluate RNG (RI).

In addition to the new line_* entries in sysfs, the indication for the
direction of the transmitted data is independently controllable via the
new rx and tx sysfs entrie now too. These are on by default. Thus the
trigger behaves as before this change.

- rx:
  Signal reception (rx) of data on the named tty device.
  If set to 0, the LED will not blink on reception.
  If set to 1 (default), the LED will blink on reception.

- tx:
  Signal transmission (tx) of data on the named tty device.
  If set to 0, the LED will not blink on transmission.
  If set to 1 (default), the LED will blink on transmission.

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
 .../ABI/testing/sysfs-class-led-trigger-tty   |  53 ++++
 drivers/leds/trigger/ledtrig-tty.c            | 279 +++++++++++++++++-
 2 files changed, 322 insertions(+), 10 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-tty b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
index 2bf6b24e781b..e1f578ac8656 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-tty
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
@@ -4,3 +4,56 @@ KernelVersion:	5.10
 Contact:	linux-leds@vger.kernel.org
 Description:
 		Specifies the tty device name of the triggering tty
+
+What:		/sys/class/leds/<led>/rx
+Date:		September 2023
+KernelVersion:	6.7
+Description:
+		Signal reception (rx) of data on the named tty device.
+		If set to 0, the LED will not blink on reception.
+		If set to 1 (default), the LED will blink on reception.
+
+What:		/sys/class/leds/<led>/tx
+Date:		September 2023
+KernelVersion:	6.7
+Description:
+		Signal transmission (tx) of data on the named tty device.
+		If set to 0, the LED will not blink on transmission.
+		If set to 1 (default), the LED will blink on transmission.
+
+What:		/sys/class/leds/<led>/line_cts
+Date:		September 2023
+KernelVersion:	6.7
+Description:
+		DCE is ready to accept data from the DTE (Clear To Send). If
+		the line state is detected, the LED is switched on.
+		If set to 0 (default), the LED will not evaluate CTS.
+		If set to 1, the LED will evaluate CTS.
+
+What:		/sys/class/leds/<led>/line_dsr
+Date:		September 2023
+KernelVersion:	6.7
+Description:
+		DCE is ready to receive and send data (Data Set Ready). If
+		the line state is detected, the LED is switched on.
+		If set to 0 (default), the LED will not evaluate DSR.
+		If set to 1, the LED will evaluate DSR.
+
+What:		/sys/class/leds/<led>/line_car
+Date:		September 2023
+KernelVersion:	6.7
+Description:
+		DTE is receiving a carrier from the DCE (Data Carrier Detect).
+		If the line state is detected, the LED is switched on.
+		If set to 0 (default), the LED will not evaluate CAR (DCD).
+		If set to 1, the LED will evaluate CAR (DCD).
+
+What:		/sys/class/leds/<led>/line_rng
+Date:		September 2023
+KernelVersion:	6.7
+Description:
+		DCE has detected an incoming ring signal on the telephone
+		line (Ring Indicator). If the line state is detected, the
+		LED is switched on.
+		If set to 0 (default), the LED will not evaluate RNG (RI).
+		If set to 1, the LED will evaluate RNG (RI).
diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
index 1c6fadf0b856..50bef4c8f321 100644
--- a/drivers/leds/trigger/ledtrig-tty.c
+++ b/drivers/leds/trigger/ledtrig-tty.c
@@ -16,6 +16,28 @@ struct ledtrig_tty_data {
 	const char *ttyname;
 	struct tty_struct *tty;
 	int rx, tx;
+	unsigned long mode;
+#define LEDTRIG_TTY_MODE_TX	0
+#define LEDTRIG_TTY_MODE_RX	1
+#define LEDTRIG_TTY_MODE_CTS	2
+#define LEDTRIG_TTY_MODE_DSR	3
+#define LEDTRIG_TTY_MODE_CAR	4
+#define LEDTRIG_TTY_MODE_RNG	5
+};
+
+enum tty_led_state {
+	TTY_LED_BLINK,
+	TTY_LED_ENABLE,
+	TTY_LED_DISABLE,
+};
+
+enum ledtrig_tty_attr {
+	LEDTRIG_TTY_ATTR_TX,
+	LEDTRIG_TTY_ATTR_RX,
+	LEDTRIG_TTY_ATTR_CTS,
+	LEDTRIG_TTY_ATTR_DSR,
+	LEDTRIG_TTY_ATTR_CAR,
+	LEDTRIG_TTY_ATTR_RNG,
 };
 
 static void ledtrig_tty_restart(struct ledtrig_tty_data *trigger_data)
@@ -78,14 +100,186 @@ static ssize_t ttyname_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(ttyname);
 
+static ssize_t ledtrig_tty_attr_show(struct device *dev, char *buf,
+	enum ledtrig_tty_attr attr)
+{
+	struct ledtrig_tty_data *trigger_data = led_trigger_get_drvdata(dev);
+	int bit;
+
+	switch (attr) {
+	case LEDTRIG_TTY_ATTR_TX:
+		bit = LEDTRIG_TTY_MODE_TX;
+		break;
+	case LEDTRIG_TTY_ATTR_RX:
+		bit = LEDTRIG_TTY_MODE_RX;
+		break;
+	case LEDTRIG_TTY_ATTR_CTS:
+		bit = LEDTRIG_TTY_MODE_CTS;
+		break;
+	case LEDTRIG_TTY_ATTR_DSR:
+		bit = LEDTRIG_TTY_MODE_DSR;
+		break;
+	case LEDTRIG_TTY_ATTR_CAR:
+		bit = LEDTRIG_TTY_MODE_CAR;
+		break;
+	case LEDTRIG_TTY_ATTR_RNG:
+		bit = LEDTRIG_TTY_MODE_RNG;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return sprintf(buf, "%u\n", test_bit(bit, &trigger_data->mode));
+}
+
+static ssize_t ledtrig_tty_attr_store(struct device *dev, const char *buf,
+	size_t size, enum ledtrig_tty_attr attr)
+{
+	struct ledtrig_tty_data *trigger_data = led_trigger_get_drvdata(dev);
+	unsigned long state;
+	int ret;
+	int bit;
+
+	ret = kstrtoul(buf, 0, &state);
+	if (ret)
+		return ret;
+
+	switch (attr) {
+	case LEDTRIG_TTY_ATTR_TX:
+		bit = LEDTRIG_TTY_MODE_TX;
+		break;
+	case LEDTRIG_TTY_ATTR_RX:
+		bit = LEDTRIG_TTY_MODE_RX;
+		break;
+	case LEDTRIG_TTY_ATTR_CTS:
+		bit = LEDTRIG_TTY_MODE_CTS;
+		break;
+	case LEDTRIG_TTY_ATTR_DSR:
+		bit = LEDTRIG_TTY_MODE_DSR;
+		break;
+	case LEDTRIG_TTY_ATTR_CAR:
+		bit = LEDTRIG_TTY_MODE_CAR;
+		break;
+	case LEDTRIG_TTY_ATTR_RNG:
+		bit = LEDTRIG_TTY_MODE_RNG;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (state)
+		set_bit(bit, &trigger_data->mode);
+	else
+		clear_bit(bit, &trigger_data->mode);
+
+	return size;
+}
+
+static ssize_t tx_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	return ledtrig_tty_attr_show(dev, buf, LEDTRIG_TTY_ATTR_TX);
+}
+
+static ssize_t tx_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t size)
+{
+	return ledtrig_tty_attr_store(dev, buf, size, LEDTRIG_TTY_ATTR_TX);
+}
+static DEVICE_ATTR_RW(tx);
+
+static ssize_t rx_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	return ledtrig_tty_attr_show(dev, buf, LEDTRIG_TTY_ATTR_RX);
+}
+
+static ssize_t rx_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t size)
+{
+	return ledtrig_tty_attr_store(dev, buf, size, LEDTRIG_TTY_ATTR_RX);
+}
+static DEVICE_ATTR_RW(rx);
+
+static ssize_t line_cts_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	return ledtrig_tty_attr_show(dev, buf, LEDTRIG_TTY_ATTR_CTS);
+}
+
+static ssize_t line_cts_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t size)
+{
+	return ledtrig_tty_attr_store(dev, buf, size, LEDTRIG_TTY_ATTR_CTS);
+}
+static DEVICE_ATTR_RW(line_cts);
+
+static ssize_t line_dsr_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	return ledtrig_tty_attr_show(dev, buf, LEDTRIG_TTY_ATTR_DSR);
+}
+
+static ssize_t line_dsr_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t size)
+{
+	return ledtrig_tty_attr_store(dev, buf, size, LEDTRIG_TTY_ATTR_DSR);
+}
+static DEVICE_ATTR_RW(line_dsr);
+
+static ssize_t line_car_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	return ledtrig_tty_attr_show(dev, buf, LEDTRIG_TTY_ATTR_CAR);
+}
+
+static ssize_t line_car_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t size)
+{
+	return ledtrig_tty_attr_store(dev, buf, size, LEDTRIG_TTY_ATTR_CAR);
+}
+static DEVICE_ATTR_RW(line_car);
+
+static ssize_t line_rng_show(struct device *dev,
+	struct device_attribute *attr, char *buf)
+{
+	return ledtrig_tty_attr_show(dev, buf, LEDTRIG_TTY_ATTR_RNG);
+}
+
+static ssize_t line_rng_store(struct device *dev,
+	struct device_attribute *attr, const char *buf, size_t size)
+{
+	return ledtrig_tty_attr_store(dev, buf, size, LEDTRIG_TTY_ATTR_RNG);
+}
+static DEVICE_ATTR_RW(line_rng);
+
+
+static int ledtrig_tty_flag(struct ledtrig_tty_data *trigger_data, unsigned int flag)
+{
+	unsigned int status;
+	int ret;
+
+	status = tty_get_tiocm(trigger_data->tty);
+	if (status & flag)
+		ret = 1;
+	else
+		ret = 0;
+
+	return ret;
+}
+
 static void ledtrig_tty_work(struct work_struct *work)
 {
 	struct ledtrig_tty_data *trigger_data =
 		container_of(work, struct ledtrig_tty_data, dwork.work);
+	struct led_classdev *led_cdev = trigger_data->led_cdev;
 	unsigned long interval = LEDTRIG_TTY_INTERVAL;
 	struct serial_icounter_struct icount;
+	enum tty_led_state state;
+	int current_brightness;
 	int ret;
 
+	state = TTY_LED_DISABLE;
 	mutex_lock(&trigger_data->mutex);
 
 	if (!trigger_data->ttyname) {
@@ -116,20 +310,75 @@ 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 (test_bit(LEDTRIG_TTY_MODE_CTS, &trigger_data->mode)) {
+		ret = ledtrig_tty_flag(trigger_data, TIOCM_CTS);
+		if (ret)
+			state = TTY_LED_ENABLE;
 	}
 
-	if (icount.rx != trigger_data->rx ||
-	    icount.tx != trigger_data->tx) {
+	if (test_bit(LEDTRIG_TTY_MODE_DSR, &trigger_data->mode)) {
+		ret = ledtrig_tty_flag(trigger_data, TIOCM_DSR);
+		if (ret)
+			state = TTY_LED_ENABLE;
+	}
+
+	if (test_bit(LEDTRIG_TTY_MODE_CAR, &trigger_data->mode)) {
+		ret = ledtrig_tty_flag(trigger_data, TIOCM_CAR);
+		if (ret)
+			state = TTY_LED_ENABLE;
+	}
+
+	if (test_bit(LEDTRIG_TTY_MODE_RNG, &trigger_data->mode)) {
+		ret = ledtrig_tty_flag(trigger_data, TIOCM_RNG);
+		if (ret)
+			state = TTY_LED_ENABLE;
+	}
+
+	/* The rx/tx handling must come after the evaluation of TIOCM_*,
+	 * since the display for rx/tx has priority
+	 */
+	if (test_bit(LEDTRIG_TTY_MODE_TX, &trigger_data->mode) ||
+	    test_bit(LEDTRIG_TTY_MODE_RX, &trigger_data->mode)) {
+		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 (test_bit(LEDTRIG_TTY_MODE_TX, &trigger_data->mode) &&
+		    (icount.tx != trigger_data->tx)) {
+			trigger_data->tx = icount.tx;
+			state = TTY_LED_BLINK;
+		}
+
+		if (test_bit(LEDTRIG_TTY_MODE_RX, &trigger_data->mode) &&
+		    (icount.rx != trigger_data->rx)) {
+			trigger_data->rx = icount.rx;
+			state = TTY_LED_BLINK;
+		}
+	}
+
+	current_brightness = led_cdev->brightness;
+	if (current_brightness)
+		led_cdev->blink_brightness = current_brightness;
+
+	if (!led_cdev->blink_brightness)
+		led_cdev->blink_brightness = led_cdev->max_brightness;
+
+	switch (state) {
+	case TTY_LED_BLINK:
 		led_blink_set_oneshot(trigger_data->led_cdev, &interval,
 				      &interval, 0);
-
-		trigger_data->rx = icount.rx;
-		trigger_data->tx = icount.tx;
+		break;
+	case TTY_LED_ENABLE:
+		led_set_brightness(led_cdev, led_cdev->blink_brightness);
+		break;
+	case TTY_LED_DISABLE:
+		fallthrough;
+	default:
+		led_set_brightness(led_cdev, LED_OFF);
+		break;
 	}
 
 out:
@@ -140,6 +389,12 @@ static void ledtrig_tty_work(struct work_struct *work)
 
 static struct attribute *ledtrig_tty_attrs[] = {
 	&dev_attr_ttyname.attr,
+	&dev_attr_rx.attr,
+	&dev_attr_tx.attr,
+	&dev_attr_line_cts.attr,
+	&dev_attr_line_dsr.attr,
+	&dev_attr_line_car.attr,
+	&dev_attr_line_rng.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(ledtrig_tty);
@@ -152,6 +407,10 @@ static int ledtrig_tty_activate(struct led_classdev *led_cdev)
 	if (!trigger_data)
 		return -ENOMEM;
 
+	/* Enable default rx/tx LED blink */
+	set_bit(LEDTRIG_TTY_MODE_TX, &trigger_data->mode);
+	set_bit(LEDTRIG_TTY_MODE_RX, &trigger_data->mode);
+
 	led_set_trigger_data(led_cdev, trigger_data);
 
 	INIT_DELAYED_WORK(&trigger_data->dwork, ledtrig_tty_work);
-- 
2.30.2

Re: [PATCH v2 1/4] tty: whitespaces in descriptions corrected by replacing tabs with spaces.

[Jiri Slaby]

On 28. 09. 23, 15:26, Florian Eckert wrote:
> Tabs were used in the function description, to make this look more
> uniform, the tabs were replaced by spaces where necessary.
> 
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>

Reviewed-by: Jiri Slaby <jirislaby@kernel.org>

thanks,
-- 
js
suse labs

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Jiri Slaby]

On 28. 09. 23, 15:26, Florian Eckert wrote:
> The Intel build robot has complained about this.

How exactly?

> Hence move the commit
> of the variable definition to the beginning of the function.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> ---
>   drivers/leds/trigger/ledtrig-tty.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
> index 8ae0d2d284af..1c6fadf0b856 100644
> --- a/drivers/leds/trigger/ledtrig-tty.c
> +++ b/drivers/leds/trigger/ledtrig-tty.c
> @@ -82,6 +82,7 @@ static void ledtrig_tty_work(struct work_struct *work)
>   {
>   	struct ledtrig_tty_data *trigger_data =
>   		container_of(work, struct ledtrig_tty_data, dwork.work);
> +	unsigned long interval = LEDTRIG_TTY_INTERVAL;
>   	struct serial_icounter_struct icount;
>   	int ret;
>   
> @@ -124,8 +125,6 @@ static void ledtrig_tty_work(struct work_struct *work)
>   
>   	if (icount.rx != trigger_data->rx ||
>   	    icount.tx != trigger_data->tx) {
> -		unsigned long interval = LEDTRIG_TTY_INTERVAL;

It's in a block, so what's the matter?

>   		led_blink_set_oneshot(trigger_data->led_cdev, &interval,
>   				      &interval, 0);
>   

-- 
js
suse labs

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Lee Jones]

On Thu, 28 Sep 2023, Florian Eckert wrote:

> The Intel build robot has complained about this. Hence move the commit
> of the variable definition to the beginning of the function.

Please copy the robot's error message into the commit message.

> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> ---
>  drivers/leds/trigger/ledtrig-tty.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
> index 8ae0d2d284af..1c6fadf0b856 100644
> --- a/drivers/leds/trigger/ledtrig-tty.c
> +++ b/drivers/leds/trigger/ledtrig-tty.c
> @@ -82,6 +82,7 @@ static void ledtrig_tty_work(struct work_struct *work)
>  {
>  	struct ledtrig_tty_data *trigger_data =
>  		container_of(work, struct ledtrig_tty_data, dwork.work);
> +	unsigned long interval = LEDTRIG_TTY_INTERVAL;
>  	struct serial_icounter_struct icount;
>  	int ret;
>  
> @@ -124,8 +125,6 @@ static void ledtrig_tty_work(struct work_struct *work)
>  
>  	if (icount.rx != trigger_data->rx ||
>  	    icount.tx != trigger_data->tx) {
> -		unsigned long interval = LEDTRIG_TTY_INTERVAL;
> -
>  		led_blink_set_oneshot(trigger_data->led_cdev, &interval,
>  				      &interval, 0);
>  
> -- 
> 2.30.2
> 

-- 
Lee Jones [李琼斯]

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Jiri Slaby]

On 02. 10. 23, 16:05, Lee Jones wrote:
> On Thu, 28 Sep 2023, Florian Eckert wrote:
> 
>> The Intel build robot has complained about this. Hence move the commit
>> of the variable definition to the beginning of the function.
> 
> Please copy the robot's error message into the commit message.

Ah, lkp, then also the Closes: line as it suggests.

>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
>> ---
>>   drivers/leds/trigger/ledtrig-tty.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
>> index 8ae0d2d284af..1c6fadf0b856 100644
>> --- a/drivers/leds/trigger/ledtrig-tty.c
>> +++ b/drivers/leds/trigger/ledtrig-tty.c
>> @@ -82,6 +82,7 @@ static void ledtrig_tty_work(struct work_struct *work)
>>   {
>>   	struct ledtrig_tty_data *trigger_data =
>>   		container_of(work, struct ledtrig_tty_data, dwork.work);
>> +	unsigned long interval = LEDTRIG_TTY_INTERVAL;
>>   	struct serial_icounter_struct icount;
>>   	int ret;
>>   
>> @@ -124,8 +125,6 @@ static void ledtrig_tty_work(struct work_struct *work)
>>   
>>   	if (icount.rx != trigger_data->rx ||
>>   	    icount.tx != trigger_data->tx) {
>> -		unsigned long interval = LEDTRIG_TTY_INTERVAL;
>> -
>>   		led_blink_set_oneshot(trigger_data->led_cdev, &interval,
>>   				      &interval, 0);
>>   
>> -- 
>> 2.30.2
>>
> 

-- 
js
suse labs

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Florian Eckert]

On 2023-10-03 07:00, Jiri Slaby wrote:
> On 02. 10. 23, 16:05, Lee Jones wrote:
>> On Thu, 28 Sep 2023, Florian Eckert wrote:
>> 
>>> The Intel build robot has complained about this. Hence move the 
>>> commit
>>> of the variable definition to the beginning of the function.

>> Please copy the robot's error message into the commit message.

For a v3 patch-set I will add the error message from build robot.

Build robot output of my v1 change:
https://lore.kernel.org/linux-leds/20230926093607.59536-1-fe@dev.tdt.de/T/#m777371c5de8fadc505a833139b8ae69ac7fa8dab

I decided to move the variable definition with a separate commit
to the top of the function, to make the build robot happy. After that
I made my changes for v2 to the ledtrig-tty to add the feature.

> Ah, lkp, then also the Closes: line as it suggests.

Sorry I do not understand your statement

>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
>>> ---
>>>   drivers/leds/trigger/ledtrig-tty.c | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>> 
>>> diff --git a/drivers/leds/trigger/ledtrig-tty.c 
>>> b/drivers/leds/trigger/ledtrig-tty.c
>>> index 8ae0d2d284af..1c6fadf0b856 100644
>>> --- a/drivers/leds/trigger/ledtrig-tty.c
>>> +++ b/drivers/leds/trigger/ledtrig-tty.c
>>> @@ -82,6 +82,7 @@ static void ledtrig_tty_work(struct work_struct 
>>> *work)
>>>   {
>>>   	struct ledtrig_tty_data *trigger_data =
>>>   		container_of(work, struct ledtrig_tty_data, dwork.work);
>>> +	unsigned long interval = LEDTRIG_TTY_INTERVAL;
>>>   	struct serial_icounter_struct icount;
>>>   	int ret;
>>>   @@ -124,8 +125,6 @@ static void ledtrig_tty_work(struct work_struct 
>>> *work)
>>>     	if (icount.rx != trigger_data->rx ||
>>>   	    icount.tx != trigger_data->tx) {
>>> -		unsigned long interval = LEDTRIG_TTY_INTERVAL;
>>> -
>>>   		led_blink_set_oneshot(trigger_data->led_cdev, &interval,
>>>   				      &interval, 0);
>>>   -- 2.30.2
>>> 
>> 

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Jiri Slaby]

On 04. 10. 23, 8:37, Florian Eckert wrote:
> On 2023-10-03 07:00, Jiri Slaby wrote:
>> On 02. 10. 23, 16:05, Lee Jones wrote:
>>> On Thu, 28 Sep 2023, Florian Eckert wrote:
>>>
>>>> The Intel build robot has complained about this. Hence move the commit
>>>> of the variable definition to the beginning of the function.
> 
>>> Please copy the robot's error message into the commit message.
> 
> For a v3 patch-set I will add the error message from build robot.
> 
> Build robot output of my v1 change:
> https://lore.kernel.org/linux-leds/20230926093607.59536-1-fe@dev.tdt.de/T/#m777371c5de8fadc505a833139b8ae69ac7fa8dab
> 
> I decided to move the variable definition with a separate commit
> to the top of the function, to make the build robot happy. After that
> I made my changes for v2 to the ledtrig-tty to add the feature.
> 
>> Ah, lkp, then also the Closes: line as it suggests.
> 
> Sorry I do not understand your statement

The link you pasted above states:
=======
If you fix the issue in a separate patch/commit (i.e. not just a new 
version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/
=======

So please follow that suggestion ;).

thanks,
-- 
js
suse labs

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Florian Eckert]

>> I decided to move the variable definition with a separate commit
>> to the top of the function, to make the build robot happy. After that
>> I made my changes for v2 to the ledtrig-tty to add the feature.
>> 
>>> Ah, lkp, then also the Closes: line as it suggests.
>> 
>> Sorry I do not understand your statement
> 
> The link you pasted above states:
> =======
> If you fix the issue in a separate patch/commit (i.e. not just a new 
> version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/
> =======
> 
> So please follow that suggestion ;).

Ok, I understand, thanks will to this on a v3 patchset.
I will now wait for the comments of my changes in ledtrig-tty from the 
led subsystem.
And then I will send a new patch set with the requested changes.

Sorry for the silly question. But do I have to send this patch again for 
a v3?
https://lore.kernel.org/linux-leds/f41dc1e1-6d34-48b2-97dd-ba67df6003c6@kernel.org/T/#u
It was already marked by you with a `Reviewed-by:` from you?

--
Best regards
Florian

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Jiri Slaby]

On 04. 10. 23, 10:36, Florian Eckert wrote:
> Sorry for the silly question. But do I have to send this patch again for 
> a v3?
> https://lore.kernel.org/linux-leds/f41dc1e1-6d34-48b2-97dd-ba67df6003c6@kernel.org/T/#u
> It was already marked by you with a `Reviewed-by:` from you?

If it is not picked up by Greg by then, I would send it with my rev-b 
already.

thanks,
-- 
js
suse labs

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Greg KH]

On Wed, Oct 04, 2023 at 10:36:09AM +0200, Florian Eckert wrote:
> 
> 
> > > I decided to move the variable definition with a separate commit
> > > to the top of the function, to make the build robot happy. After that
> > > I made my changes for v2 to the ledtrig-tty to add the feature.
> > > 
> > > > Ah, lkp, then also the Closes: line as it suggests.
> > > 
> > > Sorry I do not understand your statement
> > 
> > The link you pasted above states:
> > =======
> > If you fix the issue in a separate patch/commit (i.e. not just a new
> > version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes:
> > https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/
> > =======
> > 
> > So please follow that suggestion ;).
> 
> Ok, I understand, thanks will to this on a v3 patchset.
> I will now wait for the comments of my changes in ledtrig-tty from the led
> subsystem.
> And then I will send a new patch set with the requested changes.
> 
> Sorry for the silly question. But do I have to send this patch again for a
> v3?
> https://lore.kernel.org/linux-leds/f41dc1e1-6d34-48b2-97dd-ba67df6003c6@kernel.org/T/#u
> It was already marked by you with a `Reviewed-by:` from you?

This series is long gone from my review queue, so a v3 will be needed at
the very least.

thanks,

greg k-h

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Lee Jones]

On Thu, 05 Oct 2023, Greg KH wrote:

> On Wed, Oct 04, 2023 at 10:36:09AM +0200, Florian Eckert wrote:
> > 
> > 
> > > > I decided to move the variable definition with a separate commit
> > > > to the top of the function, to make the build robot happy. After that
> > > > I made my changes for v2 to the ledtrig-tty to add the feature.
> > > > 
> > > > > Ah, lkp, then also the Closes: line as it suggests.
> > > > 
> > > > Sorry I do not understand your statement
> > > 
> > > The link you pasted above states:
> > > =======
> > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes:
> > > https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/
> > > =======
> > > 
> > > So please follow that suggestion ;).
> > 
> > Ok, I understand, thanks will to this on a v3 patchset.
> > I will now wait for the comments of my changes in ledtrig-tty from the led
> > subsystem.
> > And then I will send a new patch set with the requested changes.
> > 
> > Sorry for the silly question. But do I have to send this patch again for a
> > v3?
> > https://lore.kernel.org/linux-leds/f41dc1e1-6d34-48b2-97dd-ba67df6003c6@kernel.org/T/#u
> > It was already marked by you with a `Reviewed-by:` from you?

Yes please.  I will pick this up as a set once it's ready.

> This series is long gone from my review queue, so a v3 will be needed at
> the very least.

Nothing for Greg to worry about here (unless you *want* to review).

-- 
Lee Jones [李琼斯]

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Greg KH]

On Thu, Oct 05, 2023 at 11:13:07AM +0100, Lee Jones wrote:
> On Thu, 05 Oct 2023, Greg KH wrote:
> 
> > On Wed, Oct 04, 2023 at 10:36:09AM +0200, Florian Eckert wrote:
> > > 
> > > 
> > > > > I decided to move the variable definition with a separate commit
> > > > > to the top of the function, to make the build robot happy. After that
> > > > > I made my changes for v2 to the ledtrig-tty to add the feature.
> > > > > 
> > > > > > Ah, lkp, then also the Closes: line as it suggests.
> > > > > 
> > > > > Sorry I do not understand your statement
> > > > 
> > > > The link you pasted above states:
> > > > =======
> > > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > > version of
> > > > the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > | Closes:
> > > > https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/
> > > > =======
> > > > 
> > > > So please follow that suggestion ;).
> > > 
> > > Ok, I understand, thanks will to this on a v3 patchset.
> > > I will now wait for the comments of my changes in ledtrig-tty from the led
> > > subsystem.
> > > And then I will send a new patch set with the requested changes.
> > > 
> > > Sorry for the silly question. But do I have to send this patch again for a
> > > v3?
> > > https://lore.kernel.org/linux-leds/f41dc1e1-6d34-48b2-97dd-ba67df6003c6@kernel.org/T/#u
> > > It was already marked by you with a `Reviewed-by:` from you?
> 
> Yes please.  I will pick this up as a set once it's ready.
> 
> > This series is long gone from my review queue, so a v3 will be needed at
> > the very least.
> 
> Nothing for Greg to worry about here (unless you *want* to review).

Yes, I want to ensure that the tty change is correct, last round I
didn't think it was...

thanks,

greg k-h

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Lee Jones]

On Thu, 05 Oct 2023, Greg KH wrote:

> On Thu, Oct 05, 2023 at 11:13:07AM +0100, Lee Jones wrote:
> > On Thu, 05 Oct 2023, Greg KH wrote:
> > 
> > > On Wed, Oct 04, 2023 at 10:36:09AM +0200, Florian Eckert wrote:
> > > > 
> > > > 
> > > > > > I decided to move the variable definition with a separate commit
> > > > > > to the top of the function, to make the build robot happy. After that
> > > > > > I made my changes for v2 to the ledtrig-tty to add the feature.
> > > > > > 
> > > > > > > Ah, lkp, then also the Closes: line as it suggests.
> > > > > > 
> > > > > > Sorry I do not understand your statement
> > > > > 
> > > > > The link you pasted above states:
> > > > > =======
> > > > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > > > version of
> > > > > the same patch/commit), kindly add following tags
> > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > | Closes:
> > > > > https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/
> > > > > =======
> > > > > 
> > > > > So please follow that suggestion ;).
> > > > 
> > > > Ok, I understand, thanks will to this on a v3 patchset.
> > > > I will now wait for the comments of my changes in ledtrig-tty from the led
> > > > subsystem.
> > > > And then I will send a new patch set with the requested changes.
> > > > 
> > > > Sorry for the silly question. But do I have to send this patch again for a
> > > > v3?
> > > > https://lore.kernel.org/linux-leds/f41dc1e1-6d34-48b2-97dd-ba67df6003c6@kernel.org/T/#u
> > > > It was already marked by you with a `Reviewed-by:` from you?
> > 
> > Yes please.  I will pick this up as a set once it's ready.
> > 
> > > This series is long gone from my review queue, so a v3 will be needed at
> > > the very least.
> > 
> > Nothing for Greg to worry about here (unless you *want* to review).
> 
> Yes, I want to ensure that the tty change is correct, last round I
> didn't think it was...

Sounds good, thanks.

-- 
Lee Jones [李琼斯]

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Florian Eckert]

Hello Lee,

I only got reviews for the fixes and preparations for commits that 
change the
tty subsystem, but no reaction from the maintainer of the feature I want 
to
add to ledtrig-tty for v1 and v2 patchset.

How should I proceed? Send a v3 with the the requested changes.

[Patch v2 1/4]: 
https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#m913d3822465f35b54dfa24b1dfe4d50e61352980
Change got a 'Reviewed-by: Jiri Slaby <jirislaby@kernel.org>'.
Will add this to an upcoming v3 again.

[Patch v2 2/4] : 
https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#m7ee7618894a66fd3c89bed488a2394265a3f8df1
I missed to add the robot error message to the commit message and also 
missed
to add the the following 'Reported-by: kernel test robot 
<lkp@intel.com>' and
'Closes: 
https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/'
to the commit message. Will add this to an upcoming v3.

And do not wait for the review of the following patches.
https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#mc0ecb912fa0e59015ad0a9b4cb491ae9f18c1ea9
https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#mba36217323c386ecd900e188bbdf6276c3c96c91

---

Florian

Re: [PATCH v2 3/4] trigger: ledtrig-tty: move variable definition to the top

[Lee Jones]

On Wed, 11 Oct 2023, Florian Eckert wrote:

> Hello Lee,
> 
> I only got reviews for the fixes and preparations for commits that change
> the
> tty subsystem, but no reaction from the maintainer of the feature I want to
> add to ledtrig-tty for v1 and v2 patchset.
> 
> How should I proceed? Send a v3 with the the requested changes.
> 
> [Patch v2 1/4]: https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#m913d3822465f35b54dfa24b1dfe4d50e61352980
> Change got a 'Reviewed-by: Jiri Slaby <jirislaby@kernel.org>'.
> Will add this to an upcoming v3 again.
> 
> [Patch v2 2/4] : https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#m7ee7618894a66fd3c89bed488a2394265a3f8df1
> I missed to add the robot error message to the commit message and also
> missed
> to add the the following 'Reported-by: kernel test robot <lkp@intel.com>'
> and
> 'Closes:
> https://lore.kernel.org/oe-kbuild-all/202309270440.IJB24Xap-lkp@intel.com/'
> to the commit message. Will add this to an upcoming v3.
> 
> And do not wait for the review of the following patches.
> https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#mc0ecb912fa0e59015ad0a9b4cb491ae9f18c1ea9
> https://lore.kernel.org/linux-leds/20230928132632.200263-1-fe@dev.tdt.de/T/#mba36217323c386ecd900e188bbdf6276c3c96c91

Yes.  I've removed this from my queue.

Better to resend it with the fixes.

-- 
Lee Jones [李琼斯]