From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org, Hans Verkuil <hverkuil-cisco@xs4all.nl>
Subject: Re: [PATCH v2 24/29] media: Documentation: Document how Media device resources are released
Date: Wed, 21 Feb 2024 11:37:14 +0000 [thread overview]
Message-ID: <ZdXgaoIpt12ICnQO@kekkonen.localdomain> (raw)
In-Reply-To: <20240207144304.GU23702@pendragon.ideasonboard.com>
Hi Laurent,
On Wed, Feb 07, 2024 at 04:43:04PM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Wed, Dec 20, 2023 at 12:37:08PM +0200, Sakari Ailus wrote:
> > Document that after unregistering, Media device memory resources are
> > released by the release() callback rather than by calling
> > media_device_cleanup().
> >
> > Also add that driver memory resources should be bound to the Media device,
> > not V4L2 device.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > ---
> > Documentation/driver-api/media/mc-core.rst | 18 ++++++++++++++++--
> > include/media/media-device.h | 6 ++++--
> > 2 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst
> > index 2456950ce8ff..346f67760671 100644
> > --- a/Documentation/driver-api/media/mc-core.rst
> > +++ b/Documentation/driver-api/media/mc-core.rst
> > @@ -46,13 +46,27 @@ Drivers initialise media device instances by calling
> > :c:func:`media_device_init()`. After initialising a media device instance, it is
> > registered by calling :c:func:`__media_device_register()` via the macro
> > ``media_device_register()`` and unregistered by calling
> > -:c:func:`media_device_unregister()`. An initialised media device must be
> > -eventually cleaned up by calling :c:func:`media_device_cleanup()`.
> > +:c:func:`media_device_unregister()`. The resources of an unregistered media
>
> "of an unregistered media device" sounds weird here, I interpret it as
> applying only to media devices that have never been registered.
How about "newly unregistered"?
>
> > +device will be released by the ``release()`` callback of :c:type:`media_device`
> > +ops, which will be called when the last user of the media device has released it
> > +calling :c:func:`media_device_put()`.
> > +
> > +The ``release()`` callback is the way all the resources of the media device are
> > +released once :c:func:`media_device_init()` has been called. This is also
> > +relevant during device driver's probe function as the ``release()`` callback
> > +will also have to be able to safely release the resources related to a partially
> > +initialised media device.
> >
> > Note that it is not allowed to unregister a media device instance that was not
> > previously registered, or clean up a media device instance that was not
> > previously initialised.
>
> Does this need an update, as we don't cleanup explicitly instead ?
I think this should remain unchanged, at least as long as there are drivers
using the old API.
>
> >
> > +Media device and driver's per-device context
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Drivers should use the struct media_device_ops ``release()`` callback to release
> > +their own resources and not e.g. that of the struct v4l2_device.
> > +
> > Entities
> > ^^^^^^^^
> >
> > diff --git a/include/media/media-device.h b/include/media/media-device.h
> > index c6816be0eee8..98e1892f1b51 100644
> > --- a/include/media/media-device.h
> > +++ b/include/media/media-device.h
> > @@ -250,8 +250,10 @@ void media_device_init(struct media_device *mdev);
> > *
> > * @mdev: pointer to struct &media_device
> > *
> > - * This function that will destroy the graph_mutex that is
> > - * initialized in media_device_init().
> > + * This function that will destroy the graph_mutex that is initialized in
>
> While at it, s/that will/will/
Yes.
>
> > + * media_device_init(). Note that *only* drivers that do not manage releasing
> > + * the memory of th media device itself call this function. This function is
>
> s/of th/of the/
>
> "that do not manage releasing the memory of the media device itself" is
> hard to understand for someone who hasn't paid close attention to the
> development of this series. This text needs improvements.
Hmm. How about:
Note that only drivers that do not have a proper release callback of the
struct media_device call this function.
>
> > + * thus effectively DEPRECATED.
> > */
> > void media_device_cleanup(struct media_device *mdev);
> >
>
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2024-02-21 11:37 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 10:36 [PATCH v2 00/29] Media device lifetime management Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 01/29] Revert "[media] media: fix media devnode ioctl/syscall and unregister race" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 02/29] Revert "media: utilize new cdev_device_add helper function" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 03/29] Revert "[media] media: fix use-after-free in cdev_put() when app exits after driver unbind" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 04/29] media: mc: utilize new cdev_device_add helper function Sakari Ailus
2024-02-07 9:38 ` Laurent Pinchart
2024-02-07 9:51 ` Laurent Pinchart
2024-02-21 12:55 ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 05/29] Revert "media: uvcvideo: Refactor teardown of uvc on USB disconnect" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 06/29] Revert "[media] media-device: dynamically allocate struct media_devnode" Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 07/29] media: uvcvideo: Refactor teardown of uvc on USB disconnect Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 08/29] media: mc: Drop nop release callback Sakari Ailus
2024-02-07 9:55 ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 09/29] media: mc: Do not call cdev_device_del() if cdev_device_add() fails Sakari Ailus
2024-02-07 9:57 ` Laurent Pinchart
2024-03-05 8:13 ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 10/29] media: mc: Delete character device early Sakari Ailus
2024-02-07 10:08 ` Laurent Pinchart
2024-03-05 8:52 ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 11/29] media: mc: Split initialising and adding media devnode Sakari Ailus
2024-02-07 10:46 ` Laurent Pinchart
2024-03-05 8:59 ` Sakari Ailus
2023-12-20 10:36 ` [PATCH v2 12/29] media: mc: Shuffle functions around Sakari Ailus
2024-02-07 10:47 ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 13/29] media: mc: Initialise media devnode in media_device_init() Sakari Ailus
2024-02-07 10:51 ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 14/29] media: mc: Refactor media devnode minor clearing Sakari Ailus
2024-02-05 14:46 ` Hans Verkuil
2024-02-07 10:53 ` Laurent Pinchart
2023-12-20 10:36 ` [PATCH v2 15/29] media: mc: Unassign minor only if it has been assigned Sakari Ailus
2024-02-05 14:48 ` Hans Verkuil
2024-02-07 10:58 ` Laurent Pinchart
2024-02-21 9:24 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 16/29] media: mc: Refcount the media device Sakari Ailus
2024-02-07 11:08 ` Laurent Pinchart
2024-03-07 10:37 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 17/29] media: v4l: Acquire a reference to the media device for every video device Sakari Ailus
2024-02-05 14:56 ` Hans Verkuil
2024-02-07 11:13 ` Laurent Pinchart
2024-02-21 10:43 ` Sakari Ailus
2024-02-21 12:19 ` Laurent Pinchart
2024-02-21 12:35 ` Sakari Ailus
2024-02-21 10:40 ` Sakari Ailus
2024-02-21 10:51 ` Hans Verkuil
2024-02-21 11:44 ` Sakari Ailus
2024-03-05 7:43 ` Sakari Ailus
2024-03-05 7:46 ` Hans Verkuil
2023-12-20 10:37 ` [PATCH v2 18/29] media: mc: Postpone graph object removal until free Sakari Ailus
2024-02-07 14:18 ` Laurent Pinchart
2024-06-04 10:59 ` Sakari Ailus
2024-06-04 11:01 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 19/29] media: omap3isp: Release the isp device struct by media device callback Sakari Ailus
2024-02-07 14:23 ` Laurent Pinchart
2024-06-05 9:23 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 20/29] media: ipu3-cio2: Call v4l2_device_unregister() earlier Sakari Ailus
2024-02-07 14:24 ` Laurent Pinchart
2024-03-05 10:21 ` Sakari Ailus
2024-03-05 10:22 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 21/29] media: ipu3-cio2: Request IRQ earlier Sakari Ailus
2024-02-05 14:58 ` Hans Verkuil
2024-02-07 14:34 ` Laurent Pinchart
2024-02-21 10:51 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 22/29] media: ipu3-cio2: Release the cio2 device context by media device callback Sakari Ailus
2024-02-07 14:33 ` Laurent Pinchart
2024-03-07 12:23 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 23/29] media: vimc: Release resources on media device release Sakari Ailus
2024-02-05 15:02 ` Hans Verkuil
2024-02-07 14:38 ` Laurent Pinchart
2024-02-21 10:55 ` Sakari Ailus
2024-02-21 10:53 ` Sakari Ailus
2024-02-21 11:02 ` Laurent Pinchart
2024-02-21 11:38 ` Sakari Ailus
2024-02-21 11:19 ` Hans Verkuil
2024-02-21 11:40 ` Sakari Ailus
2024-02-21 11:48 ` Hans Verkuil
2024-02-21 12:02 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 24/29] media: Documentation: Document how Media device resources are released Sakari Ailus
2024-02-05 15:04 ` Hans Verkuil
2024-02-07 14:43 ` Laurent Pinchart
2024-02-21 11:37 ` Sakari Ailus [this message]
2023-12-20 10:37 ` [PATCH v2 25/29] media: mc: Add per-file-handle data support Sakari Ailus
2024-02-05 15:08 ` Hans Verkuil
2023-12-20 10:37 ` [PATCH v2 26/29] media: mc: Maintain a list of open file handles in a media device Sakari Ailus
2024-02-05 15:11 ` Hans Verkuil
2024-02-05 15:16 ` Laurent Pinchart
2024-02-05 15:32 ` Hans Verkuil
2024-02-05 15:41 ` Laurent Pinchart
2024-02-21 11:53 ` Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 27/29] media: mc: Implement best effort media device removal safety sans refcount Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 28/29] media: mc: Warn about drivers not releasing media device safely Sakari Ailus
2023-12-20 10:37 ` [PATCH v2 29/29] media: Documentation: Document media device memory safety helper Sakari Ailus
2023-12-20 10:52 ` [PATCH v2 00/29] Media device lifetime management Laurent Pinchart
2023-12-20 11:30 ` Sakari Ailus
2024-02-07 10:55 ` Laurent Pinchart
2024-03-07 10:57 ` Sakari Ailus
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=ZdXgaoIpt12ICnQO@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/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