From: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
To: Linmao Li <lilinmao@kylinos.cn>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Jacopo Mondi" <jacopo.mondi+renesas@ideasonboard.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] media: rcar-isp: Release ISPCORE resources
Date: Mon, 3 Aug 2026 16:17:12 +0200 [thread overview]
Message-ID: <anChUtV090GkJ6VI@zed> (raw)
In-Reply-To: <20260803090553.4082161-2-lilinmao@kylinos.cn>
Hi Linmao Li
On Mon, Aug 03, 2026 at 05:05:53PM +0800, Linmao Li wrote:
> v4l2_device_register() takes a reference to the parent device, but the
> ISPCORE remove path never calls v4l2_device_unregister(). The reference
> is therefore leaked whenever an ISPCORE is removed.
>
> Probe failures after rppx1_create() also return without destroying the
> RPPX1 object.
>
> Unregister the V4L2 device and destroy the RPPX1 object on the
> corresponding error paths, and unregister the V4L2 device during removal.
> v4l2_device_unregister() also unregisters all attached subdevices, so it
> replaces the narrower subdevice-only cleanup.
>
> Fixes: 2151350f60d1 ("media: rcar-isp: Add support for ISPCORE")
The driver has not landed in any Linux release, but it has just been
collected for the next merge window.
If your patches get collected as part of the same cycle, I don't think
there's any need for a Fixes tag ?
> Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
> ---
> drivers/media/platform/renesas/rcar-isp/core.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/renesas/rcar-isp/core.c b/drivers/media/platform/renesas/rcar-isp/core.c
> index 8dafffdd8de68..923970fd7841f 100644
> --- a/drivers/media/platform/renesas/rcar-isp/core.c
> +++ b/drivers/media/platform/renesas/rcar-isp/core.c
> @@ -883,17 +883,23 @@ int risp_core_probe(struct rcar_isp_core *core, struct platform_device *pdev,
>
> ret = v4l2_device_register(core->dev, &core->v4l2_dev);
> if (ret)
> - return ret;
> + goto err_destroy_rpp;
>
> ret = risp_core_create_subdev(core);
> if (ret)
> - return ret;
> + goto err_unregister_v4l2;
>
> mutex_init(&core->io_lock);
> spin_lock_init(&core->lock);
> INIT_LIST_HEAD(&core->risp_jobs);
>
> return 0;
> +
> +err_unregister_v4l2:
> + v4l2_device_unregister(&core->v4l2_dev);
> +err_destroy_rpp:
> + rppx1_destroy(core->rpp);
> + return ret;
> }
>
> void risp_core_remove(struct rcar_isp_core *core)
> @@ -907,7 +913,7 @@ void risp_core_remove(struct rcar_isp_core *core)
> for (unsigned int i = 0; i < RISP_CORE_NUM_PADS; i++)
> risp_core_io_destroy(&core->io[i]);
>
> - v4l2_device_unregister_subdev(&core->subdev);
> + v4l2_device_unregister(&core->v4l2_dev);
As v4l2_device_unregister() unregister all subdevs of core->v4l2_dev,
this seems correct to me.
R-Car ISP is a little complicated, in the sense that the core->subdev
gets registered by risp_cs_registered() which is the handler of the
channel selector subdev .registered() callback, and to properly
balance we should unregister it in the (not implemented)
.unregistered() handler.
However, as this is called as part of the driver's remove handler, and
that's what we have at the moment, I guess this is ok
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
>
> mutex_destroy(&core->io_lock);
> rppx1_destroy(core->rpp);
> --
> 2.25.1
>
>
next prev parent reply other threads:[~2026-08-03 14:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 9:05 [PATCH 1/2] media: rcar-isp: Fix VSPX reference leaks Linmao Li
2026-08-03 9:05 ` [PATCH 2/2] media: rcar-isp: Release ISPCORE resources Linmao Li
2026-08-03 14:17 ` Jacopo Mondi [this message]
2026-08-04 2:25 ` Linmao Li
2026-08-04 8:54 ` Niklas Söderlund
2026-08-03 13:43 ` [PATCH 1/2] media: rcar-isp: Fix VSPX reference leaks Jacopo Mondi
2026-08-04 2:05 ` Linmao Li
2026-08-04 8:51 ` Niklas Söderlund
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=anChUtV090GkJ6VI@zed \
--to=jacopo.mondi@ideasonboard.com \
--cc=geert+renesas@glider.be \
--cc=jacopo.mondi+renesas@ideasonboard.com \
--cc=lilinmao@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mchehab@kernel.org \
--cc=niklas.soderlund@ragnatech.se \
--cc=sakari.ailus@linux.intel.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