From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
To: Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
Cc: linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Subject: [PATCH 0/5] remoteproc: Use devm_of_reserved_mem_device_init()
Date: Thu, 3 Sep 2026 01:03:13 +0530 [thread overview]
Message-ID: <20260902193318.1996827-1-mukesh.ojha@oss.qualcomm.com> (raw)
Several remoteproc drivers manually allocate a reserved memory region via
of_reserved_mem_device_init() and then pair it with an explicit release in
the remove path. This is error-prone: if any error path between init and
release is taken, the region is leaked for the lifetime of the driver, and
the pattern must be duplicated for every driver that needs this.
devm_of_reserved_mem_device_init() was recently introduced to handle the
cleanup automatically via the devres framework. Convert the affected
remoteproc drivers to use it, removing the manual release calls and any
wrapper devres actions that were added to work around the missing helper.
Mukesh Ojha (5):
remoteproc: da8xx: Use devm_of_reserved_mem_device_init()
remoteproc: keystone: Use devm_of_reserved_mem_device_init()
remoteproc: omap: Use devm_of_reserved_mem_device_init()
remoteproc: mtk_scp: Use devm_of_reserved_mem_device_init()
remoteproc: ti_k3: Use devm_of_reserved_mem_device_init()
drivers/remoteproc/da8xx_remoteproc.c | 10 +---------
drivers/remoteproc/keystone_remoteproc.c | 16 ++--------------
drivers/remoteproc/omap_remoteproc.c | 13 +------------
drivers/remoteproc/mtk_scp.c | 3 +--
drivers/remoteproc/ti_k3_common.c | 13 +------------
drivers/remoteproc/ti_k3_common.h | 1 -
6 files changed, 6 insertions(+), 50 deletions(-)
--
2.34.1
next reply other threads:[~2026-09-02 19:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 19:33 Mukesh Ojha [this message]
2026-09-02 19:33 ` [PATCH 1/5] remoteproc: da8xx: Use devm_of_reserved_mem_device_init() Mukesh Ojha
2026-09-02 19:33 ` [PATCH 2/5] remoteproc: keystone: " Mukesh Ojha
2026-09-02 19:33 ` [PATCH 3/5] remoteproc: omap: " Mukesh Ojha
2026-09-02 19:33 ` [PATCH 4/5] remoteproc: mtk_scp: " Mukesh Ojha
2026-09-02 19:33 ` [PATCH 5/5] remoteproc: ti_k3: " Mukesh Ojha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902193318.1996827-1-mukesh.ojha@oss.qualcomm.com \
--to=mukesh.ojha@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=matthias.bgg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox