[PATCH v3 0/2] serial: core: Don't clobber the baud rate on hangup via B0
From: Maciej W. Rozycki
Date: Tue Nov 03 2026 - 17:13:54 EST
Greg,
This is v3 of the change for device baud rate preservation where the B0
rate has been requested for hangup that we discussed at LPC.
Following the observations regarding v2 I have now excluded the 8250
console restoration path from rewriting port->hup_speed; this path only
takes the most recent baud rate previously set and reinstates it with
hardware without changing the setting chosen. See the individual patches
for further details of the changes made.
I have verified it with the system and driver originally affected, that
is a Broadcom BCM91250A "SWARM" system and sb1250-duart driver, but now
also an MTI Malta system and the 8250 driver, with both showing the same
symptoms on real hardware (worth mentioning since Malta is commonly used
emulated in QEMU); cf. SIBYTE_SWARM and MIPS_MALTA in arch/mips/Kconfig.
I have retained the console output logs previously attached for the bad vs
fixed case; output is virtually the same across both systems.
All that needed to be done to reproduce it was to keep killing getty(8)s
repeatedly until init(8) decided something was wrong and chose to put
their inittab(5) entries into a snooze, leaving the line(s) at the wrong
speed setting. I have done further experimentation with actual kernel
console output by issuing:
# echo h >/proc/sysrq-trigger
once the console port has been hung up and that obviously also produced
corrupt output without the fix and correct output with the fix applied.
I have no means to verify the serial8250_console_restore() path; the fix
is expected to make no functional change there.
Since the return path from uart_get_baud_rate() has become more complex
now than just supplying the baud rate chosen to the caller I went back to
the original idea of having this as a small patch series, where 1/2 merely
merges the two successful return paths into one.
NB this fixes the missing %B0 literal markup as a part of the doc update.
I've concluded it's not worth splitting off into a separate patch. Let me
know if you think otherwise.
Previous iterations:
- v2 at: <https://lore.kernel.org/r/alpine.DEB.2.21.2610120150230.55767@xxxxxxxxxxxxxxxxx/>.
- v1 at: <https://lore.kernel.org/r/alpine.DEB.2.21.2605242242330.1450@xxxxxxxxxxxxxxxxx/>.
Maciej[H[J
swarm.orcam.me.uk login: þ