Thread (35 messages) flat view 35 messages, 6 authors, 19d ago

Re: [PATCH v5 10/12] serial: 8250: add Ambarella UART driver

From: sashiko-bot@kernel.org
Date: 2026-08-18 10:50:36
Also in: linux-clk

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Data race on up->ier and premature hardware interrupt enablement in ambarella_startup().
- [Medium] Silent drop of accumulated UART error and break status in ambarella_idle_enter().
--
--- Patch [10]: [PATCH v5 10/12] serial: 8250: add Ambarella UART driver ---
commit 766436c7b1daf21bb460e72b46363bc9a4c0f145
Author: Long Zhao [off-list ref]

serial: 8250: add Ambarella UART driver

This patch adds an 8250 platform driver for Ambarella CV75 instead of claiming
snps,dw-apb-uart compatibility.
quoted hunk ↗ jump to hunk
diff --git a/drivers/tty/serial/8250/8250_ambarella.c b/drivers/tty/serial/8250/8250_ambarella.c
new file mode 100644
index 0000000000000..951355e19fa25
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_ambarella.c
[ ... ]
+static int ambarella_idle_enter(struct uart_port *p)
+{
[ ... ]
+	status = serial_lsr_in(up);
+	if (status & UART_LSR_DR) {
+		readl(p->membase + (UART_RX << p->regshift));
+		up->lsr_saved_flags = 0;
[Severity: Medium]
Will this unconditionally clear any pending parity, framing, overrun errors,
or break conditions accumulated in lsr_saved_flags by the preceding call
to serial_lsr_in()? If so, this could prevent the interrupt handler from
reporting these conditions to the upper layers, resulting in lost break
signals.
+	}
+
+	if (readl(p->membase + (AMBARELLA_UART_USR << p->regshift)) &
+	    AMBARELLA_UART_USR_BUSY) {
+		ambarella_idle_exit(p);
+		return -EBUSY;
+	}
+
+	return 0;
+}
[ ... ]
+static int ambarella_startup(struct uart_port *port)
+{
+	struct uart_8250_port *up = up_to_u8250p(port);
+	int ret;
+
+	ret = serial8250_do_startup(port);
+	if (ret)
+		return ret;
+
+	up->ier |= AMBARELLA_UART_IER_ETOI;
+	serial_port_out(port, UART_IER, up->ier);
[Severity: High]
Does modifying up->ier and writing it to UART_IER here without holding
port->lock cause a data race with concurrent console writes
(e.g., serial8250_console_write()), which also manipulates interrupts under
the lock? 

Additionally, doesn't writing the IER register here defeat the 8250 core's
intentional deferral of interrupt enablement? The core typically defers
writing to UART_IER until set_termios to avoid swamping the interrupt handler
before the FIFOs are configured.
+
+	return 0;
+}
-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818-cv75-v5-v5-0-7bbb12f0360f@ambarella.com?part=10
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help