Re: [PATCH 16/19] drivers: tty: serial: ma35d1_serial: Migrate to register_console_force helper

Petr Mladek
2026-01-15T16:28:50Z

On Sat 2025-12-27 09:16:23, Marcos Paulo de Souza wrote:
> The register_console_force function was introduced to register consoles
> even on the presence of default consoles, replacing the CON_ENABLE flag
> that was forcing the same behavior.
>
> No functional changes.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> ---
> drivers/tty/serial/ma35d1_serial.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/ma35d1_serial.c b/drivers/tty/serial/ma35d1_serial.c
> index 285b0fe41a86..d1e03dee5579 100644
> --- a/drivers/tty/serial/ma35d1_serial.c
> +++ b/drivers/tty/serial/ma35d1_serial.c
> @@ -633,7 +633,7 @@ static struct console ma35d1serial_console = {
> .write = ma35d1serial_console_write,
> .device = uart_console_device,
> .setup = ma35d1serial_console_setup,
> - .flags = CON_PRINTBUFFER | CON_ENABLED,
> + .flags = CON_PRINTBUFFER,
> .index = -1,
> .data = &ma35d1serial_reg,
> };
> @@ -657,7 +657,7 @@ static void ma35d1serial_console_init_port(void)
> static int __init ma35d1serial_console_init(void)
> {
> ma35d1serial_console_init_port();
> - register_console(&ma35d1serial_console);
> + register_console_force(&ma35d1serial_console);

Sigh, I am afraid that this is not enough.

I double checked how "ma35d1serial_console" was used. I guess
that it could get registered also via the generic uart device
driver code. I see the following:

#ifdef CONFIG_SERIAL_NUVOTON_MA35D1_CONSOLE
[...]
#define MA35D1SERIAL_CONSOLE (&ma35d1serial_console)
#else
#define MA35D1SERIAL_CONSOLE NULL
#endif

static struct uart_driver ma35d1serial_reg = {
[...]
.cons = MA35D1SERIAL_CONSOLE,
[...]
};

static int __init ma35d1serial_init(void)
{
[...]
ret = uart_register_driver(&ma35d1serial_reg);
[...]
ret = platform_driver_register(&ma35d1serial_driver);
[...]
}

And the gneric code:

uart_configure_port(struct uart_driver *drv, struct uart_state *state,
struct uart_port *port)
{
[...]
/*
* If this driver supports console, and it hasn't been
* successfully registered yet, try to re-register it.
* It may be that the port was not available.
*/
if (port->cons && !console_is_registered(port->cons))
register_console(port->cons);

[...]
}

, which can called via from:

+ mux_probe()
+ uart_add_one_port()
+ serial_ctrl_register_port()
+serial_core_register_port()
+ serial_core_add_one_port()
+ uart_configure_port()
+ register_console()

Honestly, I am not 100% sure. The struct console is assigned to
.cons in struct uart_driver. And uart_configure_port() function
passes port->cons from struct uart_port *port. But I believe
that they can get assigned somewhere in the maze of
the init/probe code.

I would feel more comfortable if we kept the information as
as flag in struct console so that even the generic callbacks
could use it.

Anyway, it makes sense to create a sepate flag for this
purpose, e.g. CON_FORCE or CON_FORCE_ENABLE.

> return 0;
> }
> console_initcall(ma35d1serial_console_init);

Best Regards,
Petr