linux-kernel - Re: [PATCH v12 1/1] serial: core: Start managing serial controllers to enable runtime PM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Jun 2023 16:20:12 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...el.com>,
        Dhruva Gole <d-gole@...com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        John Ogness <john.ogness@...utronix.de>,
        Johan Hovold <johan@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-omap@...r.kernel.org,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH v12 1/1] serial: core: Start managing serial controllers
 to enable runtime PM

* Tony Lindgren <tony@...mide.com> [230601 11:12]:
> * Marek Szyprowski <m.szyprowski@...sung.com> [230601 11:00]:
> > This patch landed in today's linux next-20230601 as commit 84a9582fd203 
> > ("serial: core: Start managing serial controllers to enable runtime 
> > PM"). Unfortunately it breaks booting some of my test boards. This can 
> > be easily reproduced with QEMU and ARM64 virt machine. The last message 
> > I see in the log is:
> > 
> > [    3.084743] Run /sbin/init as init process
> 
> OK thanks for the report. I wonder if this issue is specific to ttyAM
> serial port devices somehow?

Looks like the problem happens with serial port drivers that use
arch_initcall():

$ git grep arch_initcall drivers/tty/serial/
drivers/tty/serial/amba-pl011.c:arch_initcall(pl011_init);
drivers/tty/serial/mps2-uart.c:arch_initcall(mps2_uart_init);
drivers/tty/serial/mvebu-uart.c:arch_initcall(mvebu_uart_init);
drivers/tty/serial/pic32_uart.c:arch_initcall(pic32_uart_init);
drivers/tty/serial/serial_base_bus.c:arch_initcall(serial_base_init);
drivers/tty/serial/xilinx_uartps.c:arch_initcall(cdns_uart_init);

We have serial_base_bus use module_init() so the serial core controller
and port device associated with the physical serial port are not probed.

The patch below should fix the problem you're seeing, care to test and
if it works I'll post a proper fix?

Note that if we ever have cases where uart_add_one_port() gets called
even earlier, we should just call serial_base_init() directly when
adding the first port.

Regards,

Tony

8< ------------------
diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -186,7 +186,7 @@ static int serial_base_init(void)
 
 	return ret;
 }
-module_init(serial_base_init);
+arch_initcall(serial_base_init);
 
 static void serial_base_exit(void)
 {
-- 
2.40.1