From: Sultan Alsawaf <sultan@kerneltoast.com>
To: "Du, Bin" <bin.du@amd.com>
Cc: mchehab@kernel.org, hverkuil@xs4all.nl,
laurent.pinchart+renesas@ideasonboard.com,
bryan.odonoghue@linaro.org, sakari.ailus@linux.intel.com,
prabhakar.mahadev-lad.rj@bp.renesas.com,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
pratap.nirujogi@amd.com, benjamin.chan@amd.com, king.li@amd.com,
gjorgji.rosikopulos@amd.com, Phil.Jawich@amd.com,
Dominic.Antony@amd.com, mario.limonciello@amd.com,
richard.gong@amd.com, anson.tsao@amd.com,
Alexey Zagorodnikov <xglooom@gmail.com>
Subject: Re: [PATCH v4 5/7] media: platform: amd: isp4 video node and buffers handling added
Date: Sun, 19 Oct 2025 15:11:13 -0700 [thread overview]
Message-ID: <aPViAdn4Z8OAO1lj@sultan-box> (raw)
In-Reply-To: <3ff43351-9236-43a6-aea8-ab492cc86699@amd.com>
On Fri, Oct 17, 2025 at 05:53:27PM +0800, Du, Bin wrote:
> On 10/17/2025 4:34 PM, Sultan Alsawaf wrote:
> > On Thu, Oct 16, 2025 at 04:13:47PM +0800, Du, Bin wrote:
> > > On 10/11/2025 5:30 PM, Du, Bin wrote:
> > > > On 10/1/2025 2:53 PM, Sultan Alsawaf wrote:
> > > > > On Thu, Sep 11, 2025 at 06:08:45PM +0800, Bin Du wrote:
> > > > > > +++ b/drivers/media/platform/amd/isp4/isp4.c
> > > > > > @@ -178,6 +178,16 @@ static int isp4_capture_probe(struct
> > > > > > platform_device *pdev)
> > > > > > goto err_isp4_deinit;
> > > > > > }
> > > > > > + ret = media_create_pad_link(&isp_dev->isp_sdev.sdev.entity,
> > > > > > + 0, &isp_dev->isp_sdev.isp_vdev.vdev.entity,
> > > > > > + 0,
> > > > > > + MEDIA_LNK_FL_ENABLED |
> > > > > > + MEDIA_LNK_FL_IMMUTABLE);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "fail to create pad link %d\n", ret);
> > > > > > + goto err_isp4_deinit;
> > > > > > + }
> > > > > > +
> > > > >
> > > > > Two problems with this hunk:
> > > > >
> > > > > 1. According to the comment in include/media/media-device.h [1],
> > > > > media_create_pad_link() should be called before
> > > > > media_device_register():
> > > > >
> > > > > * So drivers need to first initialize the media device,
> > > > > register any entity
> > > > > * within the media device, create pad to pad links and then
> > > > > finally register
> > > > > * the media device by calling media_device_register() as a
> > > > > final step.
> > > > >
> > > > > 2. Missing call to media_device_unregister() on error when
> > > > > media_create_pad_link() fails.
> > > > >
> > > > > Since the media_create_pad_link() will be moved before
> > > > > media_device_register(),
> > > > > we will need to clean up media_create_pad_link() when
> > > > > media_device_register()
> > > > > fails.
> > > > >
> > > > > The clean-up function for media_create_pad_link() is
> > > > > media_device_unregister().
> > > > > According to the comment for media_device_unregister() [2], it is
> > > > > safe to call
> > > > > media_device_unregister() on an unregistered media device that is
> > > > > initialized
> > > > > (through media_device_init()).
> > > > >
> > > > > In addition, this made me realize that there's no call to
> > > > > media_device_cleanup()
> > > > > in the entire driver too. This is the cleanup function for
> > > > > media_device_init(),
> > > > > so it should be called on error and on module unload.
> > > > >
> > > > > To summarize, make the following changes:
> > > > >
> > > > > 1. Move the media_create_pad_link() up, right before
> > > > > media_device_register().
> > > > >
> > > > > 2. When media_device_register() fails, clean up
> > > > > media_create_pad_link() by
> > > > > calling media_device_unregister().
> > > > >
> > > > > 3. Add a missing call to media_device_cleanup() on error and module
> > > > > unload to
> > > > > clean up media_device_init().
> > > > >
> > > >
> > > > Very clear guide, will follow your advice.
> > > >
> > > > > > platform_set_drvdata(pdev, isp_dev);
> > > > > > return 0;
> > >
> > > For 2, we found when media_device_register() fails, calling
> > > media_device_unregister() won't clean up media_create_pad_link() because it
> > > simply returns without doing anything(see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/mc/mc-device.c?h=v6.17-rc7#n797).
> > > Therefore like other kernel drivers, we'd rather not call
> > > media_device_unregister() in this scenario, it doesn't cause issues, but
> > > it's not logically correct. Cleanup for media_create_pad_link() occurs
> > > during error handling via isp4sd_deinit()->isp4vid_dev_deinit()->vb2_video_unregister_device()->...->media_entity_remove_link().
> > > What do you think?
> >
> > Oh, good catch! You are right about media_device_unregister() not cleaning up
> > media_create_pad_link().
> >
> > But I don't see how vb2_video_unregister_device() ends up calling
> > media_entity_remove_links().
> >
> > It looks like media_create_pad_link() is actually cleaned up via
> > v4l2_device_unregister_subdev()->media_device_unregister_entity()->__media_device_unregister_entity()->__media_entity_remove_links()
> >
> > And I mentioned before to add a missing call to v4l2_device_unregister_subdev()
> > on error, so it looks like that will cover the media_create_pad_link() cleanup
> > and therefore you don't need to call media_device_unregister() in this scenario.
> >
> > Does that look correct?
> >
>
> Yes, Sultan, we moved v4l2_device_unregister_subdev to isp4sd_deinit as you
> suggested, so current isp4sd_deinit() looks like this
> void isp4sd_deinit(struct isp4_subdev *isp_subdev)
> {
> struct isp4_interface *ispif = &isp_subdev->ispif;
>
> isp4vid_dev_deinit(&isp_subdev->isp_vdev);
> v4l2_device_unregister_subdev(&isp_subdev->sdev);
> media_entity_cleanup(&isp_subdev->sdev.entity);
> isp4if_deinit(ispif);
> isp4sd_module_enable(isp_subdev, false);
>
> ispif->status = ISP4IF_STATUS_PWR_OFF;
> }
Right, and v4l2_device_unregister_subdev() is *also* needed inside isp4sd_init()
to handle cleanup on error when isp4sd_init() doesn't complete successfully.
That's what I meant in our last few emails, since isp4sd_deinit() won't be
called in that scenario. Sorry that wasn't clear.
>
> You are correct and I believe both isp4vid_dev_deinit and
> v4l2_device_unregister_subdev can cause media_create_pad_link() being
> cleaned up. Because isp4vid_dev_deinit is called first, so the link will be
> cleaned by it, here is the call stack FYI, does it make sense?
> [ 5.198328] Call Trace:
> [ 5.198329] <TASK>
> [ 5.198331] dump_stack_lvl+0x76/0xa0
> [ 5.198336] dump_stack+0x10/0x20
> [ 5.198338] __media_entity_remove_link+0xdf/0x1f0 [mc]
> [ 5.198342] __media_entity_remove_links+0x31/0x70 [mc]
> [ 5.198344] __media_device_unregister_entity+0x93/0xf0 [mc]
> [ 5.198346] media_device_unregister_entity+0x2f/0x50 [mc]
> [ 5.198348] v4l2_device_release+0x112/0x190 [videodev]
> [ 5.198355] device_release+0x38/0xa0
> [ 5.198358] kobject_put+0x9e/0x200
> [ 5.198359] put_device+0x13/0x30
> [ 5.198359] vb2_video_unregister_device+0x8e/0xd0 [videobuf2_v4l2]
> [ 5.198362] isp4vid_dev_deinit+0xe/0x20 [amd_capture]
> [ 5.198364] isp4sd_deinit+0x25/0x80 [amd_capture]
> [ 5.198366] isp4_capture_probe+0x1ec/0x2f0 [amd_capture]
> [ 5.198368] platform_probe+0x3f/0xb0
> [ 5.198370] really_probe+0xf4/0x3b0
Thanks for clarifying! I was wondering where vdev.entity gets cleaned up, and it
looks like that is where it happens. And the subdev entity, sdev.entity, gets
cleaned up by v4l2_device_unregister_subdev().
To summarize: Assuming all of my other advice is implemented, the cleanup for
media_create_pad_link() will already be handled on error and device removal. So
the only action you should take is to disregard this advice from me:
"2. When media_device_register() fails, clean up media_create_pad_link() by
calling media_device_unregister()."
And that is all. :)
Sultan
next prev parent reply other threads:[~2025-10-19 22:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-11 10:08 [PATCH v4 0/7] Add AMD ISP4 driver Bin Du
2025-09-11 10:08 ` [PATCH v4 1/7] media: platform: amd: Introduce amd isp4 capture driver Bin Du
2025-09-21 20:23 ` Sultan Alsawaf
2025-09-23 7:56 ` Du, Bin
2025-09-11 10:08 ` [PATCH v4 2/7] media: platform: amd: low level support for isp4 firmware Bin Du
2025-09-21 20:31 ` Sultan Alsawaf
2025-09-23 8:05 ` Du, Bin
2025-09-11 10:08 ` [PATCH v4 3/7] media: platform: amd: Add isp4 fw and hw interface Bin Du
2025-09-21 21:55 ` Sultan Alsawaf
2025-09-23 9:24 ` Du, Bin
2025-09-24 7:09 ` Sultan Alsawaf
2025-09-25 3:56 ` Du, Bin
2025-09-25 7:20 ` Sultan Alsawaf
2025-09-25 9:42 ` Du, Bin
2025-09-11 10:08 ` [PATCH v4 4/7] media: platform: amd: isp4 subdev and firmware loading handling added Bin Du
2025-09-23 7:23 ` Sultan Alsawaf
2025-09-30 7:30 ` Du, Bin
2025-10-01 7:24 ` Sultan Alsawaf
2025-10-10 10:25 ` Du, Bin
2025-10-11 7:18 ` Sultan Alsawaf
2025-10-11 8:27 ` Du, Bin
2025-09-11 10:08 ` [PATCH v4 5/7] media: platform: amd: isp4 video node and buffers " Bin Du
2025-10-01 6:53 ` Sultan Alsawaf
2025-10-11 9:30 ` Du, Bin
2025-10-12 6:08 ` Sultan Alsawaf
2025-10-13 9:55 ` Du, Bin
2025-10-16 8:13 ` Du, Bin
2025-10-17 8:34 ` Sultan Alsawaf
2025-10-17 9:53 ` Du, Bin
2025-10-19 22:11 ` Sultan Alsawaf [this message]
2025-09-11 10:08 ` [PATCH v4 6/7] media: platform: amd: isp4 debug fs logging and more descriptive errors Bin Du
2025-09-11 10:08 ` [PATCH v4 7/7] Documentation: add documentation of AMD isp 4 driver Bin Du
2025-09-19 3:24 ` [PATCH v4 0/7] Add AMD ISP4 driver Du, Bin
2025-09-19 12:23 ` Laurent Pinchart
2025-09-22 2:50 ` Du, Bin
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=aPViAdn4Z8OAO1lj@sultan-box \
--to=sultan@kerneltoast.com \
--cc=Dominic.Antony@amd.com \
--cc=Phil.Jawich@amd.com \
--cc=anson.tsao@amd.com \
--cc=benjamin.chan@amd.com \
--cc=bin.du@amd.com \
--cc=bryan.odonoghue@linaro.org \
--cc=gjorgji.rosikopulos@amd.com \
--cc=hverkuil@xs4all.nl \
--cc=king.li@amd.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mchehab@kernel.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=pratap.nirujogi@amd.com \
--cc=richard.gong@amd.com \
--cc=sakari.ailus@linux.intel.com \
--cc=xglooom@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.