From nobody Sat Jul 25 05:22:53 2026 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 016B73F88A2 for ; Fri, 17 Jul 2026 12:35:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784291747; cv=none; b=MVPlfAU8aNL/fIZWIQ0fRRu16YyvJjT0Ma2bAjqB2aCm4sgRqQ98ds3jJvPXxyW3AOvz+kMkY6e0oZ3Zbae7J8rhsRlTVWbCWqMOyMdhn6Mc+VR/QF7rnHo57qET/bM3V3NPP1xS3k3x0r6uWYReDA094OqbW3YV71Jc5A4SV2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784291747; c=relaxed/simple; bh=NoYERio/mf4DLekWv4MCy7+mB4/+mSN3HNuFTWNN6Mc=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=DGEQeRmleTrLS2fSHZ2xDHEAddKDOzZnvmLp7D3gk9Iy847xDHgPYK4UybVHci5vi2G6ZKJP9DX9bem7hzaZSHiTpMNAD6vu94ypdBwyChNkmOsYt14BrT+v1YUIS4FM4+GC8CTMgaCSGaV/Kg0Axxlq7D7YSOid3uqeLX2qjqc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=o7lrpT/z; arc=none smtp.client-ip=209.85.219.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="o7lrpT/z" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-8ff5d1b0f91so48607556d6.2 for ; Fri, 17 Jul 2026 05:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784291743; x=1784896543; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=lMekRXzh3ZMunw4GPDw9aK7U0CvdM1LOGZ4vytcNb5w=; b=o7lrpT/zuAOqr9ryFmpbtQgOkh4N57dX3lbTLAoLMwaXUClfMhl7ROqowhGYMeGQcJ btxjcv7y7yHHlkoqdzpDylX5e6tV6kzEPuqvhGsUddmOWZv0SD9Xac7uqAERZTHB04fB j0yNFjt9NLiKiD3P/XEFXT1VdpN3RufdrH1MhOwdMXC4Xma41O422PI1xiT0EkE1RpkI 9a1F+EOLYZJYF8i+oDtWH5vVObMm5xPj5GFvOsRGFv/cmB1+giREArwB2rQ/n8/3f3XK K44mzpglCrKJkflhOlrptCS7LwU7aqtM+Fth0dLvxgLdtqH6o0r51nI+hYTIcaWGMrJC wK7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784291743; x=1784896543; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lMekRXzh3ZMunw4GPDw9aK7U0CvdM1LOGZ4vytcNb5w=; b=YLZpHlfWgimIyzo44TJrB/8s8yRouyq4Np1IC520j+W+MML6j6q1a68eHLgtkPbSar WszjmNEp6j0WV4Uk00Us4QZsZfkis1kRhcR5lJB0OWZTfYe1/Ic8pWfH5j6JLjh1pNmR J+opXA5V80twjU66fXmM8Y20fy3zWjj16ytgnkuOClvfLfvQT6Pp+XJVsJU71lCeAc0w +EL80KYLtG9yr24fHgThEAZNPRp/Atur78DQ03QMuwYXL5QDin2gdxvCovxjUuWLP7/w YkpVAmCsntbMbwu+eA9x/W5WWhcuyG2SCrueBZpoX6It1aWTx3LtJpa+TcXVTTznf6Lz CC1w== X-Forwarded-Encrypted: i=1; AHgh+RqoZndyzrokSRWSaCfz3P8ymaE5va/7xyxWXojl0suYmyzDJHBJW0dK14SUcv0R1MZf4nh/20eVthKjn30=@vger.kernel.org X-Gm-Message-State: AOJu0YyThmHqshxGw4NhdciBCkqG0O1Ciy1lR71vQqqSrVDnHE+1/r/Q TpsWBMhW9hGP3fd30uUAmbGPf8i6h+sTYpdJvFZnliKHoTGCOEgZ2xF2FNWEKSE= X-Gm-Gg: AfdE7cnh4VBun4XKpNldZKc2u1feuvwaikalsAXt+GrJTxAMLCVdDu0e41EpulmFr6T k8IuehrnKM/R1UEArXF9XAlIaToi6mV6zVsRLhJm1Ov2Trg5AGi3oY6VaRrDNosJKCFv3nJtN0B UuEh1Jb1QtUCexyYaHUdfjLAdxXkHwosxDltgjfetbMSxkuZUQsZcvnE3rQIx4SP2xZ03oROs1L jGMVnJGVVIvysC8SAOUz4u6gdbDpLesHjhJP4b1984OI9AECdiK4ysgDOWivCUjrLttUw/Vlr53 hfv5Ub0wZJ/geGrpwQ7XVwYBsm8pwTVbdAoBSVpYTO3F1ObUh31CgHmFrodmb25tY9JghnbB32Z G2cl2GBgxIMxzPd/5Mar8YVcgbdUFVflzDUToEUB93D+1R5567BF2RRMPl7vkMfbCVsZbwHfZXa NlfyLTiE1jJS35j+C0zPc70x7zh+Zz8cLr2AGUhBx90S5pKJ0cz+dp8j4= X-Received: by 2002:ad4:5744:0:b0:8f0:3736:dff6 with SMTP id 6a1803df08f44-907784fd685mr29769246d6.46.1784291743174; Fri, 17 Jul 2026 05:35:43 -0700 (PDT) Received: from NAUTEL-9N0B043.nautel.com (host-76-11-42-59.public.eastlink.ca. [76.11.42.59]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-907786b21d6sm15558116d6.24.2026.07.17.05.35.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 05:35:42 -0700 (PDT) From: Ryan Wilbur To: Greg Kroah-Hartman , Jiri Slaby Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Andy Shevchenko , John Ogness , Manuel Lauss , Hugo Villeneuve , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Ryan Wilbur , stable@vger.kernel.org Subject: [PATCH] serial: 8250: clear stuck RX-timeout interrupt on LPC32xx (PORT_LPC3220) Date: Fri, 17 Jul 2026 09:35:30 -0300 Message-Id: <20260717123530.481021-1-rwilbur633@gmail.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The LPC32xx UART can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=3D0xcc lsr=3D0x60 ier=3D0x05, tripp= ing the soft-lockup detector in serial8250_handle_irq_locked(). Fix this by doing one throwaway RHR read to clear the timeout. It is gated on PORT_LPC3220 and only fires when the FIFO is empty (LSR.DR clear), so no real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR=3D=3D0. This is the same class of bug already worked around for other 8250 cores; see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus= rx timeout interrupt") which reports the identical iir=3D0xcc/lsr=3D0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271. Cc: stable@vger.kernel.org Signed-off-by: Ryan Wilbur --- drivers/tty/serial/8250/8250_port.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/= 8250_port.c index 8c241ec7f4f2..20014f54637b 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -1803,6 +1803,20 @@ void serial8250_handle_irq_locked(struct uart_port *= port, unsigned int iir) if (!(status & UART_LSR_DR) && (status & UART_LSR_FIFOE)) serial8250_clear_and_reinit_fifos(up); =20 + /* + * On PORT_LPC3220 the UART can raise an RX character-timeout + * interrupt with an empty RX FIFO (IIR reports RX_TIMEOUT but + * LSR.DR is clear). The timeout is only cleared by reading RHR, + * but the RX path below is skipped when the FIFO is empty, so + * nothing clears it. IRQ then re-fires immediately and livelocks + * this single-core. Do one throwaway RHR read to clear it. + * Same bug worked around for other 8250 cores (8250_dw, 8250_omap, 8250_= bcm7271). + */ + if (port->type =3D=3D PORT_LPC3220 && + (iir & UART_IIR_RX_TIMEOUT) =3D=3D UART_IIR_RX_TIMEOUT && + !(status & UART_LSR_DR)) + serial_in(up, UART_RX); + /* * If port is stopped and there are no error conditions in the * FIFO, then don't drain the FIFO, as this may lead to TTY buffer base-commit: da7b5fd4e17f8e44c5590f2d603c01d499f056e6 --=20 2.25.1