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

Message-ID: <hwykqbo2ktw4slmmb2iodeitd5fqfvzuec5eyvgnttyh3keo3h@cibdr37t4shy>
Date: Mon, 29 Dec 2025 05:18:14 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        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 Mon, Dec 22, 2025 at 11:55:26AM +0100, Marek Szyprowski wrote:
> 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.

I can confirm that this patch fixes the breakage on Qualcomm devices.
Please send it as a proper patch (though I'd say, the flag should only
be set only if dev->of_node != NULL).

An alternative is to introduce dev_set_node_from_dev() which mimics both
dev_set_node() and device_set_of_node_from_dev().

Greg, what would be your preference?

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

-- 
With best wishes
Dmitry