linux-kernel - Re: [REGRESSION] Suspend to RAM does not work anymore with k3-am62-ti-ipc-firmware.dtsi

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: <1a849a0b515c77faebe28456d6537d39d4ca32d0.camel@ew.tq-group.com>
Date: Tue, 21 Oct 2025 12:06:32 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Beleswar Prasad Padhi <b-padhi@...com>, Francesco Dolcini
	 <francesco@...cini.it>
Cc: Hiago De Franco <hiagofranco@...il.com>, nm@...com, vigneshr@...com, 
 kristo@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org,  afd@...com, u-kumar1@...com, hnagalla@...com,
 jm@...com, d-gole@...com,  devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org,  linux-arm-kernel@...ts.infradead.org, Robert
 Nelson <robertcnelson@...il.com>,  João Paulo
 Gonçalves <joao.goncalves@...adex.com>, Emanuele Ghidoli
 <emanuele.ghidoli@...adex.com>,  Francesco Dolcini
 <francesco.dolcini@...adex.com>, Logan Bristol <logan.bristol@...xas.edu>,
 Josua Mayer <josua@...id-run.com>, John Ma <jma@...tec.com>, Nathan
 Morrisson <nmorrisson@...tec.com>, Garrett Giordano <ggiordano@...tec.com>,
 Matt McKee <mmckee@...tec.com>, Wadim Egorov <w.egorov@...tec.de>, Max
 Krummenacher <max.krummenacher@...adex.com>, Stefan Eichenberger
 <stefan.eichenberger@...adex.com>, Hiago De Franco
 <hiago.franco@...adex.com>,  Diogo Ivo <diogo.ivo@...mens.com>, Li Hua Qian
 <huaqian.li@...mens.com>, Jan Kiszka <jan.kiszka@...mens.com>, Baocheng Su
 <baocheng.su@...mens.com>, Benedikt Niedermayr
 <benedikt.niedermayr@...mens.com>, regressions@...ts.linux.dev
Subject: Re: [REGRESSION] Suspend to RAM does not work anymore with
 k3-am62-ti-ipc-firmware.dtsi

On Tue, 2025-10-21 at 15:26 +0530, Beleswar Prasad Padhi wrote:
> On 21/10/25 15:04, Francesco Dolcini wrote:
> > On Tue, Oct 21, 2025 at 02:33:10PM +0530, Beleswar Prasad Padhi wrote:
> > > On 20/10/25 19:47, Hiago De Franco wrote:
> > > > DM R5 sends a message that is never consumed, since no firmware is
> > > > running on the M4 (the core is offline).
> > > 
> > > May I know why you are not running any firmware on the M4
> > > rproc? If the intention is just to run the DM R5 core on the SoC,
> > > you can disable the IPC by NOT including the
> > > "k3-am62-ti-ipc-firmware.dtsi". That was the motivation for the
> > > refactoring.
> > Verdin AM62 and AM62P are generic SoMs, that can be used for a multitude
> > of different use cases. And not having anything running on the M4 is the
> > default use case.
> 
> 
> If not having anything on M4 is the default use case, it should
> be marked as "status=disabled" in the DT.
> 
> > 
> > I think having the node in the DT is the correct way forward, if you
> > want to start the M4 firmware you need such a node, so this is enabling
> > a valid and useful use case.
> 
> 
> Having the node is fine, you can still choose to keep it
> disabled by default.

I agree with Francenso that it would be nice to keep the node enabled by default
- whether something is running on the M4 can be controlled via sysfs after all,
and may change over the runtime of the OS.

On our TQ starterkit mainboards, we'd like to provide the option to build the
BSP with or without M4 firmware without having to modify the DTS (which is
supposed to describe the hardware after all - I'm aware that this principle has
its limits, as the DT also needs to reserve memory ranges for MCU firmware
usage, but having a few unused memory reservations isn't as disruptive as
breaking suspend when the M4 is not running).

Best,
Matthias


> 
> > 
> > > List of suggestions/solutions in order of preference:
> > > 1. If no intention to enable IPC on rprocs:
> > >       Do _not_ include k3-am62-ti-ipc-firmware.dtsi
> > > 2. If intention is to enable IPC on rprocs:
> > >       Make sure rproc firmware is available in rootfs.
> > >       rproc would boot up and consume the mbox
> > >       msg, suspend would be successful. Tested this
> > >       on TI AM62x-sk with commit 1d6161617c, works
> > > 3. Add support in mbox driver to flush the pending
> > >     queues.
> > 2 is not applicable here, and 1 to me is not a good solution.
> 
> 
> Why not? Why would you power on the rproc, enable
> the mailboxes, carveout some memory if you never
> intend to use it?
> 
> >  So this
> > means that we need #3.
> > 
> > > > #regzbot introduced: 1d6161617c
> > > Would not see this as a regression, but rather a new
> > > bug for the omap-mailbox driver...
> > As a user this is just a regression. It worked fine before, it's not
> > working anymore now.
> 
> 
> Isn't this partly dependent on the filesystem as well?
> You would not see this behavior if you package the
> firmware in rootfs, which I assume you did while
> testing a49f991e740f
> 
> https://lore.kernel.org/all/20250908142826.1828676-17-b-padhi@ti.com/
> 
> > 
> > The fact that the solution might not be in the same file that introduced
> > the issue is not a reason for this not being considered a regression.
> > 
> > Francesco
> > 

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/