[PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Biju Das]

Hi All,

This series fixes several transmit problems on the SCI (PORT_SCI) and
RSCI ports of the sh-sci driver, seen on Renesas RZ SoCs:

 - Patch 1 removes the code that disables TE at the end of a
   transmission on SCI, which the hardware manual does not describe.
 - Patch 2 stops the TEI handler from turning the transmitter off
   while the xmit kfifo still holds data, which could stall or lose
   output. It also covers the TE handling that patch 1 no longer does
   in sci_transmit_chars().
 - Patch 3 skips the software clear of the TDxE flag on SCI, since
   hardware clears it on a TDR write and the extra clear caused a
   spurious TXI and a duplicated last character.
 - Patch 4 forces a TE toggle when restoring SCSCR in the console
   write path on SCI, so the TXI that restarts an interrupted drain is
   generated. Without it the RZ/G2UL console can hang during boot.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Changes in v3:
 * Updated commit description for patch#2
 * When the port is stopped with data still queued, the transmit_chars()
   paths (sci_transmit_chars() and rsci_transmit_chars()) now also swap
   TIE for TEIE, as they already did for an empty kfifo. Without this, TIE
   would keep firing with nothing the driver is allowed to send, and TEI
   would never be raised to complete the transmission.
 * Replaced sci_tx_interrupt() with port's transmit_chars() to avoid
   lock drop race in sci_tx_end_interrupt() before TX handoff.
 * Added missing has_tdxe_auto_clear init in scix_early_console_setup().
 * Replaced to_sci_port(port)->type with sci_port->type in
   serial_console_write().
- Link to v2: https://lore.kernel.org/r/20261021-g2ul_sci-v2-0-b4e038220018@bp.renesas.com
Changes in v2:
 * Updated commit header and description for patch#2 and #3.
 * Take the port lock before reading the control register, so the
   read-modify-write in sci_tx_end_interrupt() is protected.
 * Extended the pending-data check in sci_tx_end_interrupt() to cover
   x_char and a stopped port, not only a non-empty xmit kfifo.
 * Replaced the PORT_SCI check with a has_tdxe_auto_clear flag in
   struct sci_port, set from the new tdxe_auto_clear field in
   struct sci_of_data.
- Link to v1: https://lore.kernel.org/r/20261019170139.473808-1-biju.das.jz@bp.renesas.com

---
Au Dang (2):
      serial: sh-sci: Skip TDxE clear when hardware clears it automatically
      serial: sh-sci: Toggle TE when restoring SCSCR in console write on SCI

Biju Das (2):
      serial: sh-sci: Drop TE disable at end of transmission on SCI
      serial: sh-sci: Keep TX enabled on TEI while data is pending

 drivers/tty/serial/rsci.c          |  4 ++-
 drivers/tty/serial/sh-sci-common.h |  4 +++
 drivers/tty/serial/sh-sci.c        | 71 ++++++++++++++++++++++++++------------
 3 files changed, 56 insertions(+), 23 deletions(-)
---
base-commit: 8f7df005a7564bd7ffa75da9c3085d5b996f1e16
change-id: 20261020-g2ul_sci-b610606ea5b5

Best regards,
-- 
Biju Das <biju.das.jz@bp.renesas.com>

[PATCH v3 1/4] serial: sh-sci: Drop TE disable at end of transmission on SCI

[Biju Das]

From: Biju Das <biju.das.jz@bp.renesas.com>

Commit f06c2a9000eb ("tty: serial: sh-sci: Fix end of transmission on
SCI") made sci_transmit_chars() clear SCSCR.TE and return early on
PORT_SCI once the transmit FIFO is empty.

The hardware manual does not describe disabling the transmitter to end
a transmission, so this special case has no basis in the documented
programming sequence. Remove it and let SCI follow the same path as the
other port types. A plain revert no longer applies because the driver
now uses a kfifo, so the code is removed by hand.

Fixes: f06c2a9000eb ("tty: serial: sh-sci: Fix end of transmission on SCI")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * No change.
v1->v2:
 * No change.
---
 drivers/tty/serial/sh-sci.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index bd58bbfa65aa..9eb297dbc901 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1036,13 +1036,6 @@ static void sci_transmit_chars(struct uart_port *port)
 			c = port->x_char;
 			port->x_char = 0;
 		} else if (stopped || !kfifo_get(&tport->xmit_fifo, &c)) {
-			if (s->type == PORT_SCI &&
-			    kfifo_is_empty(&tport->xmit_fifo)) {
-				ctrl = sci_serial_in(port, SCSCR);
-				ctrl &= ~SCSCR_TE;
-				sci_serial_out(port, SCSCR, ctrl);
-				return;
-			}
 			break;
 		}
 

-- 
2.43.0

[PATCH v3 2/4] serial: sh-sci: Keep TX enabled on TEI while data is pending

[Biju Das]

From: Biju Das <biju.das.jz@bp.renesas.com>

sci_tx_end_interrupt() handles the transmit-end interrupt (TEI) on
SCI and RSCI ports by clearing TE and TEIE, which turns the
transmitter off. It does this unconditionally, even if the xmit kfifo
was refilled, or an x_char was queued, after the last byte was written
to the data register and before TEI fired. The pending data is then not
sent until the transmitter is re-enabled, so output stalls or is lost.

Check for pending data (x_char, or a non-empty xmit kfifo on a port
that is not stopped) before shutting the transmitter down. If there is
any, clear TEIE, set TIE and hand over to the port's transmit_chars()
op so transmission continues normally. The existing TE/TEIE teardown
path only runs once nothing is left to send.

When the port is stopped with data still queued, the transmit_chars()
paths (sci_transmit_chars() and rsci_transmit_chars()) now also swap
TIE for TEIE, as they already did for an empty kfifo. Without this, TIE
would keep firing with nothing the driver is allowed to send, and TEI
would never be raised to complete the transmission.

To keep the handler independent of the register layout, add tie and
teie masks to struct sci_port_params_bits and populate them for the
SCI, SCIF and RSCI variants.

Fixes: d61ae331d6f3 ("tty: serial: sh-sci: Add support for tx end interrupt handling")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * Updated commit description
 * When the port is stopped with data still queued, the transmit_chars()
   paths (sci_transmit_chars() and rsci_transmit_chars()) now also swap
   TIE for TEIE, as they already did for an empty kfifo. Without this, TIE
   would keep firing with nothing the driver is allowed to send, and TEI
   would never be raised to complete the transmission.
 * Replaced sci_tx_interrupt() with port's transmit_chars() to avoid
   lock drop race in sci_tx_end_interrupt() before TX handoff.
v1->v2:
 * Updated commit header and description.
 * Take the port lock before reading the control register, so the
   read-modify-write in sci_tx_end_interrupt() is protected.
 * Extended the pending-data check in sci_tx_end_interrupt() to cover
   x_char and a stopped port, not only a non-empty xmit kfifo.
---
 drivers/tty/serial/rsci.c          |  4 +++-
 drivers/tty/serial/sh-sci-common.h |  2 ++
 drivers/tty/serial/sh-sci.c        | 47 +++++++++++++++++++++++++++++---------
 3 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/serial/rsci.c b/drivers/tty/serial/rsci.c
index 40db9daa4272..0391111db8ae 100644
--- a/drivers/tty/serial/rsci.c
+++ b/drivers/tty/serial/rsci.c
@@ -465,7 +465,7 @@ static void rsci_transmit_chars(struct uart_port *port)
 	if (kfifo_len(&tport->xmit_fifo) < WAKEUP_CHARS)
 		uart_write_wakeup(port);
 
-	if (kfifo_is_empty(&tport->xmit_fifo)) {
+	if (kfifo_is_empty(&tport->xmit_fifo) || stopped) {
 		ctrl = rsci_serial_in(port, CCR0);
 		ctrl &= ~CCR0_TIE;
 		ctrl |= CCR0_TEIE;
@@ -627,6 +627,8 @@ static const struct sci_port_params_bits rsci_port_param_bits = {
 	.rxtx_enable = CCR0_RE | CCR0_TE,
 	.te_clear = CCR0_TE | CCR0_TEIE,
 	.poll_sent_bits = CSR_TDRE | CSR_TEND,
+	.tie = CCR0_TIE,
+	.teie = CCR0_TEIE
 };
 
 static const struct sci_port_params rsci_rzg3e_port_params = {
diff --git a/drivers/tty/serial/sh-sci-common.h b/drivers/tty/serial/sh-sci-common.h
index 01ff9fced803..273856fbc20b 100644
--- a/drivers/tty/serial/sh-sci-common.h
+++ b/drivers/tty/serial/sh-sci-common.h
@@ -56,6 +56,8 @@ struct sci_port_params_bits {
 	unsigned int rxtx_enable;
 	unsigned int te_clear;
 	unsigned int poll_sent_bits;
+	unsigned int tie;
+	unsigned int teie;
 };
 
 struct sci_common_regs {
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9eb297dbc901..6df25fef5a5f 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -261,13 +261,17 @@ static bool sci_uart_earlycon_dev_probing;
 static const struct sci_port_params_bits sci_sci_port_params_bits = {
 	.rxtx_enable = SCSCR_RE | SCSCR_TE,
 	.te_clear = SCSCR_TE | SCSCR_TEIE,
-	.poll_sent_bits = SCI_TDRE | SCI_TEND
+	.poll_sent_bits = SCI_TDRE | SCI_TEND,
+	.tie = SCSCR_TIE,
+	.teie = SCSCR_TEIE
 };
 
 static const struct sci_port_params_bits sci_scif_port_params_bits = {
 	.rxtx_enable = SCSCR_RE | SCSCR_TE,
 	.te_clear = SCSCR_TE | SCSCR_TEIE,
-	.poll_sent_bits = SCIF_TDFE | SCIF_TEND
+	.poll_sent_bits = SCIF_TDFE | SCIF_TEND,
+	.tie = SCSCR_TIE,
+	.teie = SCSCR_TEIE
 };
 
 static const struct sci_common_regs sci_common_regs = {
@@ -1007,6 +1011,20 @@ static int sci_rxfill(struct uart_port *port)
  *                   the interrupt related routines                       *
  * ********************************************************************** */
 
+static void sci_clr_tie_set_teie(struct uart_port *port)
+{
+	struct sci_port *s = to_sci_port(port);
+	unsigned short ctrl;
+
+	if (s->type != PORT_SCI)
+		return;
+
+	ctrl = sci_serial_in(port, SCSCR);
+	ctrl &= ~SCSCR_TIE;
+	ctrl |= SCSCR_TEIE;
+	sci_serial_out(port, SCSCR, ctrl);
+}
+
 static void sci_transmit_chars(struct uart_port *port)
 {
 	struct tty_port *tport = &port->state->port;
@@ -1050,14 +1068,10 @@ static void sci_transmit_chars(struct uart_port *port)
 	if (kfifo_len(&tport->xmit_fifo) < WAKEUP_CHARS)
 		uart_write_wakeup(port);
 	if (kfifo_is_empty(&tport->xmit_fifo)) {
-		if (s->type == PORT_SCI) {
-			ctrl = sci_serial_in(port, SCSCR);
-			ctrl &= ~SCSCR_TIE;
-			ctrl |= SCSCR_TEIE;
-			sci_serial_out(port, SCSCR, ctrl);
-		}
-
+		sci_clr_tie_set_teie(port);
 		sci_stop_tx(port);
+	} else if (stopped) {
+		sci_clr_tie_set_teie(port);
 	}
 }
 
@@ -2012,6 +2026,7 @@ static irqreturn_t sci_tx_end_interrupt(int irq, void *ptr)
 {
 	struct uart_port *port = ptr;
 	struct sci_port *s = to_sci_port(port);
+	struct tty_port *tport = &port->state->port;
 	const struct sci_common_regs *regs = s->params->common_regs;
 	unsigned long flags;
 	u32 ctrl;
@@ -2020,8 +2035,18 @@ static irqreturn_t sci_tx_end_interrupt(int irq, void *ptr)
 		return sci_tx_interrupt(irq, ptr);
 
 	uart_port_lock_irqsave(port, &flags);
-	ctrl = s->ops->read_reg(port, regs->control) &
-		~(s->params->param_bits->te_clear);
+	ctrl = s->ops->read_reg(port, regs->control);
+	if (port->x_char || (!kfifo_is_empty(&tport->xmit_fifo) &&
+			     !uart_tx_stopped(port))) {
+		ctrl &= ~(s->params->param_bits->teie);
+		ctrl |= s->params->param_bits->tie;
+		s->ops->write_reg(port, regs->control, ctrl);
+		s->ops->transmit_chars(port);
+		uart_port_unlock_irqrestore(port, flags);
+		return IRQ_HANDLED;
+	}
+
+	ctrl &= ~(s->params->param_bits->te_clear);
 	s->ops->write_reg(port, regs->control, ctrl);
 	uart_port_unlock_irqrestore(port, flags);
 

-- 
2.43.0

Re: [PATCH v3 2/4] serial: sh-sci: Keep TX enabled on TEI while data is pending

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] serial: sh-sci: race in sci_tx_end_interrupt() disables TE during active TX
--

commit 923e2f6adbb69b5ca02aeee3b6ef0ae02f38d727
Author: Biju Das <biju.das.jz@bp.renesas.com>

serial: sh-sci: Keep TX enabled on TEI while data is pending

This commit keeps the transmitter enabled in sci_tx_end_interrupt() when
pending data exists in the xmit kfifo or x_char, handing over to the port's
transmit_chars() callback instead of unconditionally clearing TE and TEIE. It
also swaps TIE for TEIE in sci_transmit_chars() and rsci_transmit_chars() when
the port is stopped.

> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 9eb297dbc9010..6df25fef5a5f5 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
[ ... ]
> @@ -2012,6 +2026,7 @@ static irqreturn_t sci_tx_end_interrupt(int irq, void *ptr)
>  {
>  	struct uart_port *port = ptr;
>  	struct sci_port *s = to_sci_port(port);
> +	struct tty_port *tport = &port->state->port;
>  	const struct sci_common_regs *regs = s->params->common_regs;
>  	unsigned long flags;
>  	u32 ctrl;
> @@ -2020,8 +2035,18 @@ static irqreturn_t sci_tx_end_interrupt(int irq, void *ptr)
>  		return sci_tx_interrupt(irq, ptr);
>  
>  	uart_port_lock_irqsave(port, &flags);
> -	ctrl = s->ops->read_reg(port, regs->control) &
> -		~(s->params->param_bits->te_clear);
> +	ctrl = s->ops->read_reg(port, regs->control);
> +	if (port->x_char || (!kfifo_is_empty(&tport->xmit_fifo) &&
> +			     !uart_tx_stopped(port))) {
> +		ctrl &= ~(s->params->param_bits->teie);
> +		ctrl |= s->params->param_bits->tie;
> +		s->ops->write_reg(port, regs->control, ctrl);
> +		s->ops->transmit_chars(port);
> +		uart_port_unlock_irqrestore(port, flags);
> +		return IRQ_HANDLED;
> +	}
> +
> +	ctrl &= ~(s->params->param_bits->te_clear);
>  	s->ops->write_reg(port, regs->control, ctrl);
>  	uart_port_unlock_irqrestore(port, flags);

[Severity: High]
Can sci_tx_end_interrupt() clear TE while newly written bytes are still
being transmitted by the hardware?

When the last byte in tport->xmit_fifo is written to the transmit data
register, sci_transmit_chars() and rsci_transmit_chars() clear TIE and set
TEIE. If new data is queued before TEI is serviced, sci_start_tx() in
drivers/tty/serial/sh-sci.c and rsci_start_tx() in drivers/tty/serial/rsci.c
enable TIE without clearing TEIE:

drivers/tty/serial/sh-sci.c:sci_start_tx() {
	...
		if (s->type == PORT_SCI)
			ctrl |= SCSCR_TE;

		sci_serial_out(port, SCSCR, ctrl | SCSCR_TIE);
	...
}

drivers/tty/serial/rsci.c:rsci_start_tx() {
	...
	ctrl = rsci_serial_in(port, CCR0);
	ctrl |= CCR0_TIE | CCR0_TE;
	rsci_serial_out(port, CCR0, ctrl);
}

In addition, when sci_tx_end_interrupt() takes the pending-data branch, it
sets s->params->param_bits->tie in regs->control while TDRE is asserted before
calling s->ops->transmit_chars(port). Even if transmit_chars() consumes all
pending bytes and clears TIE while setting TEIE, the rising edge on
SCIx_TXI_IRQ is already latched in the interrupt controller.

Because SCIx_TXI_IRQ (sci_tx_interrupt) and SCIx_TEI_IRQ
(sci_tx_end_interrupt) are separate interrupts, sci_tx_interrupt() can acquire
port->lock before a concurrent or pending sci_tx_end_interrupt() does. If
transmit_chars() drains all newly queued bytes from tport->xmit_fifo or
port->x_char into the hardware transmit data register or FIFO, the software
queues become empty while the hardware is still actively shifting out those
bytes (TEND is 0).

When sci_tx_end_interrupt() subsequently acquires port->lock, it only checks
port->x_char and kfifo_is_empty(&tport->xmit_fifo) without checking
regs->status (such as s->params->param_bits->poll_sent_bits for TEND and TDRE)
to verify that hardware transmission has actually finished. Wouldn't it then
clear s->params->param_bits->te_clear, shutting down the transmitter mid-frame
and corrupting or dropping the in-flight serial data?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261026-g2ul_sci-v3-0-b3097163edd5@bp.renesas.com?part=2

[PATCH v3 3/4] serial: sh-sci: Skip TDxE clear when hardware clears it automatically

[Biju Das]

From: Au Dang <au.dang.jx@renesas.com>

On some SCI variants, the TDxE (Transmit Data Empty) flag in SCxSR is
cleared by hardware when data is written to TDR. Clearing it again from
software via clear_SCxSR() generates a spurious TXI interrupt, causing
the last character to be transmitted twice.

Add a tdxe_auto_clear flag to struct sci_of_data, propagate it to struct
sci_port as has_tdxe_auto_clear, and skip the clear_SCxSR() call in
sci_transmit_chars() and sci_poll_put_char() when it is set. Enable the
flag for the PORT_SCI (of_sci_sci) variant.

Signed-off-by: Au Dang <au.dang.jx@renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * Added missing has_tdxe_auto_clear init in scix_early_console_setup().
v1->v2:
 * Updated commit header and description.
 * Replaced the PORT_SCI check with a has_tdxe_auto_clear flag in
   struct sci_port, set from the new tdxe_auto_clear field in
   struct sci_of_data.
---
 drivers/tty/serial/sh-sci-common.h | 2 ++
 drivers/tty/serial/sh-sci.c        | 9 +++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/sh-sci-common.h b/drivers/tty/serial/sh-sci-common.h
index 273856fbc20b..b75e5e1d3075 100644
--- a/drivers/tty/serial/sh-sci-common.h
+++ b/drivers/tty/serial/sh-sci-common.h
@@ -108,6 +108,7 @@ struct sci_of_data {
 	const struct sci_port_ops *ops;
 	unsigned short regtype;
 	unsigned short type;
+	bool tdxe_auto_clear;
 };
 
 struct sci_port {
@@ -163,6 +164,7 @@ struct sci_port {
 	bool has_rtscts;
 	bool autorts;
 	bool tx_occurred;
+	bool has_tdxe_auto_clear;
 };
 
 #define to_sci_port(uart) container_of((uart), struct sci_port, port)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 6df25fef5a5f..1a4d9467d2be 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -913,7 +913,8 @@ static void sci_poll_put_char(struct uart_port *port, unsigned char c)
 	} while (!(status & SCxSR_TDxE(port)));
 
 	sci_serial_out(port, SCxTDR, c);
-	s->ops->clear_SCxSR(port, SCxSR_TDxE_CLEAR(port) & ~SCxSR_TEND(port));
+	if (!s->has_tdxe_auto_clear)
+		s->ops->clear_SCxSR(port, SCxSR_TDxE_CLEAR(port) & ~SCxSR_TEND(port));
 }
 #endif /* CONFIG_CONSOLE_POLL || CONFIG_SERIAL_SH_SCI_CONSOLE ||
 	  CONFIG_SERIAL_SH_SCI_EARLYCON */
@@ -1063,7 +1064,8 @@ static void sci_transmit_chars(struct uart_port *port)
 		port->icount.tx++;
 	} while (--count > 0);
 
-	s->ops->clear_SCxSR(port, SCxSR_TDxE_CLEAR(port));
+	if (!s->has_tdxe_auto_clear)
+		s->ops->clear_SCxSR(port, SCxSR_TDxE_CLEAR(port));
 
 	if (kfifo_len(&tport->xmit_fifo) < WAKEUP_CHARS)
 		uart_write_wakeup(port);
@@ -3664,6 +3666,7 @@ static const struct sci_of_data of_sci_sci = {
 	.ops = &sci_port_ops,
 	.uart_ops = &sci_uart_ops,
 	.params = &sci_port_params[SCIx_SCI_REGTYPE],
+	.tdxe_auto_clear = true,
 };
 
 static const struct of_device_id of_sci_match[] __maybe_unused = {
@@ -3802,6 +3805,7 @@ static struct plat_sci_port *sci_parse_dt(struct platform_device *pdev,
 	sp->ops = data->ops;
 	sp->port.ops = data->uart_ops;
 	sp->params = data->params;
+	sp->has_tdxe_auto_clear = data->tdxe_auto_clear;
 
 	sp->has_rtscts = of_property_read_bool(np, "uart-has-rtscts");
 
@@ -4088,6 +4092,7 @@ int __init scix_early_console_setup(struct earlycon_device *device,
 	sci_ports[0].params = data->params;
 	sci_ports[0].ops = data->ops;
 	sci_ports[0].port.ops = data->uart_ops;
+	sci_ports[0].has_tdxe_auto_clear = data->tdxe_auto_clear;
 	sci_uart_earlycon = true;
 	regs = sci_ports[0].params->common_regs;
 

-- 
2.43.0

[PATCH v3 4/4] serial: sh-sci: Toggle TE when restoring SCSCR in console write on SCI

[Biju Das]

From: Au Dang <au.dang.jx@renesas.com>

When SCI0 (PORT_SCI) is the system console on RZ/G2UL, the board can
hang at the serial console output stage during boot.

ftrace shows the following sequence:

1. sci_transmit_chars() is draining the TX kfifo through TXI
   interrupts with SCSCR=0xf0 (TE=1, TIE=1, RE=1, RIE=1).

2. serial_console_write() runs in the middle of that drain. It saves
   SCSCR=0xf0, switches to polling by writing SCSCR=0x30 (TE=1, TIE=0)
   and outputs the characters with sci_poll_put_char().

3. It then restores SCSCR=0xf0 in a single write. TE is 1 both before
   and after, so there is no TE transition.

4. sci_start_tx() is then called repeatedly with SCSCR unchanged, but
   no TXI is ever raised again, so the drain never resumes and the
   console hangs.

The RZ/G2UL User's Manual (section 23.3.6, "SCI Initialization") notes
that changing SCR.TE from 1 to 0 or from 0 to 1 while SCR.TIE is 1
generates a TXI interrupt request. Without a TE transition, the TXI
that would restart the drain is never generated.

For PORT_SCI, restore SCSCR in two steps: first with TE cleared, then
with the full saved value. This forces the TE 1->0->1 transition while
TIE is being re-enabled, so TXI fires and the interrupted drain
resumes.

Signed-off-by: Au Dang <au.dang.jx@renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v2->v3:
 * Replaced to_sci_port(port)->type with sci_port->type in
   serial_console_write().
v1->v2:
 * No change.
---
 drivers/tty/serial/sh-sci.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 1a4d9467d2be..35a2f721bf56 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3456,10 +3456,14 @@ static void serial_console_write(struct console *co, const char *s,
 		cpu_relax();
 
 	/* restore the SCSCR */
-	if (sci_port->ops->finish_console_write)
+	if (sci_port->ops->finish_console_write) {
 		sci_port->ops->finish_console_write(port, ctrl);
-	else
+	} else {
+		if (sci_port->type == PORT_SCI)
+			sci_port->ops->write_reg(port, regs->control, ctrl & ~SCSCR_TE);
+
 		sci_port->ops->write_reg(port, regs->control, ctrl);
+	}
 
 	if (locked)
 		uart_port_unlock_irqrestore(port, flags);

-- 
2.43.0

Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Borislav Petkov]

On Mon, Oct 26, 2026 at 11:23:32AM +0000, Biju Das wrote:
>  drivers/tty/serial/rsci.c          |  4 ++-
>  drivers/tty/serial/sh-sci-common.h |  4 +++
>  drivers/tty/serial/sh-sci.c        | 71 ++++++++++++++++++++++++++------------
>  3 files changed, 56 insertions(+), 23 deletions(-)

$ ./scripts/get_maintainer.pl --no-rolestats -f drivers/tty/serial/rsci.c  drivers/tty/serial/sh-sci-common.h  drivers/tty/serial/sh-sci.c
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby <jirislaby@kernel.org>
Biju Das <biju.das.jz@bp.renesas.com>
Geert Uytterhoeven <geert+renesas@glider.be>
Hugo Villeneuve <hvilleneuve@dimonoff.com>
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Frank Li <Frank.Li@nxp.com>
linux-kernel@vger.kernel.org
linux-serial@vger.kernel.org

So why is

x86@kernel.org, linux-coco@lists.linux.dev

in your Cc: list?

What can those people do about Renesas-something-serial driver?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

RE: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Biju Das]

Hi Borislav Petkov,

Thanks for the feedback.

> -----Original Message-----
> From: Borislav Petkov <bp@alien8.de>
> Sent: 27 October 2026 05:58
> Subject: Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports
> 
> On Mon, Oct 26, 2026 at 11:23:32AM +0000, Biju Das wrote:
> >  drivers/tty/serial/rsci.c          |  4 ++-
> >  drivers/tty/serial/sh-sci-common.h |  4 +++
> >  drivers/tty/serial/sh-sci.c        | 71 ++++++++++++++++++++++++++------------
> >  3 files changed, 56 insertions(+), 23 deletions(-)
> 
> $ ./scripts/get_maintainer.pl --no-rolestats -f drivers/tty/serial/rsci.c  drivers/tty/serial/sh-sci-
> common.h  drivers/tty/serial/sh-sci.c Greg Kroah-Hartman <gregkh@linuxfoundation.org> Jiri Slaby
> <jirislaby@kernel.org> Biju Das <biju.das.jz@bp.renesas.com> Geert Uytterhoeven <geert+renesas@glider.be>
> Hugo Villeneuve <hvilleneuve@dimonoff.com> Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Frank Li <Frank.Li@nxp.com>
> linux-kernel@vger.kernel.org
> linux-serial@vger.kernel.org
> 
> So why is
> 
> x86@kernel.org, linux-coco@lists.linux.dev
> 
> in your Cc: list?
> 
> What can those people do about Renesas-something-serial driver?

I have been told by some maintainers to use b4 for easy review
rather than using 'git send-mail'.

If I do 'b4 prep --auto-to-cc' as per the b4 documentation,
x86@kernel.org is automatically listed.

Can you please guide me how to remove x86@kernel.org from b4 tooling
So that x86@kernel.org will not automatically listed?

Cheers,
Biju

Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Krzysztof Kozlowski]

On 27/10/2026 08:19, Biju Das wrote:
> Hi Borislav Petkov,
> 
> Thanks for the feedback.
> 
>> -----Original Message-----
>> From: Borislav Petkov <bp@alien8.de>
>> Sent: 27 October 2026 05:58
>> Subject: Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports
>>
>> On Mon, Oct 26, 2026 at 11:23:32AM +0000, Biju Das wrote:
>>>  drivers/tty/serial/rsci.c          |  4 ++-
>>>  drivers/tty/serial/sh-sci-common.h |  4 +++
>>>  drivers/tty/serial/sh-sci.c        | 71 ++++++++++++++++++++++++++------------
>>>  3 files changed, 56 insertions(+), 23 deletions(-)
>>
>> $ ./scripts/get_maintainer.pl --no-rolestats -f drivers/tty/serial/rsci.c  drivers/tty/serial/sh-sci-
>> common.h  drivers/tty/serial/sh-sci.c Greg Kroah-Hartman <gregkh@linuxfoundation.org> Jiri Slaby
>> <jirislaby@kernel.org> Biju Das <biju.das.jz@bp.renesas.com> Geert Uytterhoeven <geert+renesas@glider.be>
>> Hugo Villeneuve <hvilleneuve@dimonoff.com> Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>> Frank Li <Frank.Li@nxp.com>
>> linux-kernel@vger.kernel.org
>> linux-serial@vger.kernel.org
>>
>> So why is
>>
>> x86@kernel.org, linux-coco@lists.linux.dev
>>
>> in your Cc: list?
>>
>> What can those people do about Renesas-something-serial driver?
> 
> I have been told by some maintainers to use b4 for easy review
> rather than using 'git send-mail'.
> 
> If I do 'b4 prep --auto-to-cc' as per the b4 documentation,
> x86@kernel.org is automatically listed.

After 'b4 prep --auto-to-cc'  you edit the cover letter and see what is
there, no? You can easily spot bogus addressed added.

> 
> Can you please guide me how to remove x86@kernel.org from b4 tooling
> So that x86@kernel.org will not automatically listed?

b4 does not add these addresses for these files.

Best regards,
Krzysztof

RE: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Biju Das]

Hi Krzysztof,

Thanks for the feedback.

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 27 October 2026 07:24
> Subject: Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports
> 
> On 27/10/2026 08:19, Biju Das wrote:
> > Hi Borislav Petkov,
> >
> > Thanks for the feedback.
> >
> >> -----Original Message-----
> >> From: Borislav Petkov <bp@alien8.de>
> >> Sent: 27 October 2026 05:58
> >> Subject: Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports
> >>
> >> On Mon, Oct 26, 2026 at 11:23:32AM +0000, Biju Das wrote:
> >>>  drivers/tty/serial/rsci.c          |  4 ++-
> >>>  drivers/tty/serial/sh-sci-common.h |  4 +++
> >>>  drivers/tty/serial/sh-sci.c        | 71 ++++++++++++++++++++++++++------------
> >>>  3 files changed, 56 insertions(+), 23 deletions(-)
> >>
> >> $ ./scripts/get_maintainer.pl --no-rolestats -f
> >> drivers/tty/serial/rsci.c  drivers/tty/serial/sh-sci- common.h
> >> drivers/tty/serial/sh-sci.c Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> Jiri Slaby <jirislaby@kernel.org> Biju
> >> Das <biju.das.jz@bp.renesas.com> Geert Uytterhoeven
> >> <geert+renesas@glider.be> Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >> Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >> Frank Li <Frank.Li@nxp.com>
> >> linux-kernel@vger.kernel.org
> >> linux-serial@vger.kernel.org
> >>
> >> So why is
> >>
> >> x86@kernel.org, linux-coco@lists.linux.dev
> >>
> >> in your Cc: list?
> >>
> >> What can those people do about Renesas-something-serial driver?
> >
> > I have been told by some maintainers to use b4 for easy review rather
> > than using 'git send-mail'.
> >
> > If I do 'b4 prep --auto-to-cc' as per the b4 documentation,
> > x86@kernel.org is automatically listed.
> 
> After 'b4 prep --auto-to-cc'  you edit the cover letter and see what is there, no? You can easily spot
> bogus addressed added.

Yes, that can be done in next revision. I thought I need to follow b4
Documentation that is the reason I haven't done any address filtering.

> 
> >
> > Can you please guide me how to remove x86@kernel.org from b4 tooling
> > So that x86@kernel.org will not automatically listed?
> 
> b4 does not add these addresses for these files.

Then how x86@kernel.org added by 'b4 prep --auto-to-cc'? any pointers?

Cheers,
Biju

Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Krzysztof Kozlowski]

On 27/10/2026 09:33, Biju Das wrote:
>>
>>>
>>> Can you please guide me how to remove x86@kernel.org from b4 tooling
>>> So that x86@kernel.org will not automatically listed?
>>
>> b4 does not add these addresses for these files.
> 
> Then how x86@kernel.org added by 'b4 prep --auto-to-cc'? any pointers?

Indeed that's x86 fault, so I don't get why Borislav complains. They
added such pattern, so get_maintainers indeed reports it when run on the
patches (not with -f):

	Keyword:\b(tdx)

Best regards,
Krzysztof

Re: [PATCH v3 0/4] Fix transmit handling on SCI/RSCI ports

[Borislav Petkov]

On Tue, Oct 27, 2026 at 10:34:24AM +0100, Krzysztof Kozlowski wrote:
> Indeed that's x86 fault, so I don't get why Borislav complains.

Really, you don't?!

Looks like your mbox can take more mail then :)

> They added such pattern, so get_maintainers indeed reports it when run on
> the patches (not with -f):
> 
> 	Keyword:\b(tdx)

Probably because all those folks here haven't been bitten by the imprecise
regex issue:

https://lore.kernel.org/all/97e322a3-0526-414d-a288-835d11ee2b1a@intel.com

and I think they have but they probably didn't realize that this pattern thing
matches commit message text too.

The below fixes this particular case but I can already see it is not enough so
I think this pattern needs tightening and actually splitting it into several
patterns for easier matching.

Probably something with a path separator in it:

*./tdx(-[a-zA-Z]+/.*

and so on.

Yah, I was going to add them to Cc but the faulty pattern added them already.

Pfff.

---
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b0d9a28bc85..e727db70a2f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -30228,7 +30228,7 @@ L:      kvm@vger.kernel.org
 S:     Supported
 T:     git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/tdx
 N:     tdx
-K:     \b(tdx)
+K:     \b(tdx)\W
 
 X86 VDSO
 M:     Andy Lutomirski <luto@kernel.org>


-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette