Re: [PATCH] x86/serial: Use generic BASE_BAUD in asm/serial.h

["Arnd Bergmann" <arnd@arndb.de>]

On Fri, Jul 17, 2026, at 09:31, Thorsten Blum wrote:
>  /*
> - * This should not be an architecture specific #define, oh well.
> - *
> - * Traditionally, it just describes i8250 and related serial ports
> - * that have this clock rate.
> + * Default base baud for i8250 and related serial ports using a
> + * 1.8432 MHz UART clock.
>   */

You remove the important bit here, which is that we shouldn't need
the definition in the first place.

Among the current references

arch/arc/include/asm/serial.h:#define BASE_BAUD arc_early_base_baud()
arch/arm/mach-omap1/board-ams-delta.c:          .uartclk        = BASE_BAUD * 16,
arch/loongarch/include/asm/serial.h:#define BASE_BAUD 0
arch/openrisc/include/asm/serial.h:#define BASE_BAUD (cpuinfo_or1k[smp_processor_id()].clock_frequency/16)
arch/powerpc/include/asm/serial.h:#define BASE_BAUD ( 1843200 / 16 )
arch/powerpc/kernel/legacy_serial.c:    u32 clock = BASE_BAUD * 16;
arch/x86/boot/early_serial_console.c:#define BASE_BAUD (1843200/16)
arch/x86/boot/early_serial_console.c:   return BASE_BAUD / quot;
arch/xtensa/platforms/iss/include/platform/serial.h:#define BASE_BAUD 0
arch/xtensa/platforms/xt2000/include/platform/serial.h:#define BASE_BAUD ( DUART16552_XTAL_FREQ / 16 )
arch/xtensa/platforms/xtfpga/include/platform/serial.h:#define BASE_BAUD (*(long *)XTFPGA_CLKFRQ_VADDR / 16)
drivers/tty/serial/earlycon.c:          port->uartclk = BASE_BAUD * 16;
include/asm-generic/serial.h:#define BASE_BAUD (1843200 / 16)

the only thing actually using it is the earlycon="..." command line
parsing. As far as I can tell, everyone sets it to the generic
value, except for loongarch/xtensa-iss using 0 to make 8250-early not
override the default from the boot loader and arc/openrisc trying
to do runtime detection. The arc/openrisc case can probably be fixed
by just defining the clocks correctly in the dts files and using
chosen/stdout-path instead of the open-coded earlycon settings.
There is probably also a better solution to deal with the
BASE_BAUD=0 case in an architecture-independent way.

I should also dig out my old series that turns the architecture
specific SERIAL_PORT_DFNS macro into a regular driver.

     Arnd