linux-kernel - Re: [RFC PATCH] remoteproc: imx_dsp_rproc: Fix multiple start/stop commands

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: <CAEnQRZBV5ECT+P0FYPuS0Yt3C0xdpSmBpxjknhX0wa-c-LBXMg@mail.gmail.com>
Date: Wed, 10 Dec 2025 14:56:13 +0200
From: Daniel Baluta <daniel.baluta@...il.com>
To: Rob Herring <robh@...nel.org>
Cc: Daniel Baluta <daniel.baluta@....com>, andersson@...nel.org, mathieu.poirier@...aro.org, 
	m.szyprowski@...sung.com, shawnguo@...nel.org, kernel@...gutronix.de, 
	festevam@...il.com, arnaud.pouliquen@...s.st.com, geert+renesas@...der.be, 
	linux-remoteproc@...r.kernel.org, imx@...ts.linux.dev, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] remoteproc: imx_dsp_rproc: Fix multiple start/stop commands

On Tue, Dec 9, 2025 at 5:27 PM Rob Herring <robh@...nel.org> wrote:
>
> On Tue, Dec 09, 2025 at 04:04:25PM +0200, Daniel Baluta wrote:
> > After commit 67a7bc7f0358 ("remoteproc: Use of reserved_mem_region_*
> > functions for "memory-region"") following commands with
> > imx-dsp-rproc started to fail:
> >
> > $ echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
> > $ echo start > /sys/class/remoteproc/remoteproc0/state
> > $ echo stop > /sys/class/remoteproc/remoteproc0/state
> > $ echo start > /sys/class/remoteproc/remoteproc0/state #! This fails
> > -sh: echo: write error: Device or resource busy
>
> So unlike Marek's case, the first time works. Can you confirm your
> region is fixed address?

Yes, all regions are fixed addresses.

> > +             cpu_addr = devm_ioremap_wc(dev, res.start, resource_size(&res));
>
> Best case this is reusing the same mapping and we just have unnecessary
> ioremap and iounmap calls and devm entries. Worst case, we get a new
> virtual mapping every time. IIRC, arm32 will reuse existing mapping, but
> arm64 does not. But that's 10+ years ago I looked into it.
>
> Seems like devres is not the right lifetime. This should be just
> ioremap_wc() instead.

Yes, looks like for arm64 (imx8mp-evk) will not reuse existing mapping
but creates a new one.

Best course of action would be as Iulia suggested to move the operation
at probe instead of prepare.