serial: core: Add support for DEVNAME:0.0 style naming for kernel console
We can now add hardware based addressing for serial ports. Starting with commit 84a9582f ("serial: core: Start managing serial controllers to enable runtime PM"), and all the related fixes to this commit, the serial core now knows to which serial port controller the ports are connected. The serial ports can be addressed with DEVNAME:0.0 style naming. The names are something like 00:04:0.0 for a serial port on qemu, and something like 2800000.serial:0.0 on platform device using systems like ARM64 for example. The DEVNAME is the unique serial port hardware controller device name, AKA the name for port->dev. The 0.0 are the serial core controller id and port id. Typically 0.0 are used for each controller and port instance unless the serial port hardware controller has multiple controllers or ports. Using DEVNAME:0.0 style naming actually solves two long term issues for addressing the serial ports: 1. According to Andy Shevchenko, using DEVNAME:0.0 style naming fixes an issue where depending on the BIOS settings, the kernel serial port ttyS instance number may change if HSUART is enabled 2. Device tree using architectures no longer necessarily need to specify aliases to find a specific serial port, and we can just allocate the ttyS instance numbers dynamically in whatever probe order To do this, let's match the hardware addressing style console name to the character device name used, and add a preferred console using the character device name. Note that when using console=DEVNAME:0.0 style kernel command line, the 8250 serial console gets enabled later compared to using console=ttyS naming for ISA ports. This is because the serial port DEVNAME to character device mapping is not known until the serial driver probe time. If used together with earlycon, this issue is avoided. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20240327110021.59793-5-tony@atomide.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment