linux-kernel - Re: [PATCH v1 1/1] serial: core: Restore sysfs fwnode information

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] [day] [month] [year] [list]

Message-ID: <361ad06d-0478-40f9-9894-6f53d7b27eff@samsung.com>
Date: Mon, 22 Dec 2025 11:55:26 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org, Greg
	Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby
	<jirislaby@...nel.org>, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v1 1/1] serial: core: Restore sysfs fwnode information

On 18.12.2025 17:54, Mark Brown wrote:
> On Thu, Dec 18, 2025 at 04:29:55PM +0100, Marek Szyprowski wrote:
>> On 27.11.2025 17:36, Andy Shevchenko wrote:
>>> The change that restores sysfs fwnode information does it only for OF cases.
>>> Update the fix to cover all possible types of fwnodes.
>> This patch landed in today's linux-next as commit 24ec03cc5512 ("serial:
>> core: Restore sysfs fwnode information"). In my tests I found that it
>> breaks booting of most of my test boards (ARM 32 and 64 bit).
>> Unfortunately I cannot provide anything useful besides the information
>> that booting stops and system doesn't reach shell. There is nothing
>> suspicious in the kernel logs. I suspect a memory trashing. Reverting
>> $subject on top of linux-next fixes booting.
> I'm also seeing this in my lab and Arm's lab, there are a few systems
> that survive but it's a small minority.

I have a few spare minutes and spent them analyzing this issue.

This is somehow related to dev->of_node_reused device property and its 
check in pinctrl_bind_pins() in drivers/base/pinctrl.c.

The following hack/workaround fixes the observed boot issues:

diff --git a/drivers/tty/serial/serial_base_bus.c 
b/drivers/tty/serial/serial_base_bus.c
index 8e891984cdc0..f3332a5e134c 100644
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -76,6 +76,7 @@ static int serial_base_device_init(struct uart_port *port,
         dev->release = release;

         device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
+       dev->of_node_reused = true;

         if (!serial_base_initialized) {
                 dev_dbg(port->dev, "uart_add_one_port() called before 
arch_initcall()?\n");


If I then remove the dev->of_node_reused check in pinctrl_bind_pins(), 
the affected boards don't boot again the same way. I hope this helps 
fixing this issue.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland