Hi Laurent, On Wed, Feb 21, 2024 at 02:19:56PM +0200, Laurent Pinchart wrote: > On Wed, Feb 21, 2024 at 10:43:47AM +0000, Sakari Ailus wrote: > > Hi Laurent, > > > > Thank you for reviewing the set! > > > > On Wed, Feb 07, 2024 at 01:13:44PM +0200, Laurent Pinchart wrote: > > > On Mon, Feb 05, 2024 at 03:56:22PM +0100, Hans Verkuil wrote: > > > > On 20/12/2023 11:37, Sakari Ailus wrote: > > > > > The video device depends on the existence of its media device --- if there > > > > > is one. Acquire a reference to it. > > > > > > > > > > Note that when the media device release callback is used, then the V4L2 > > > > > device release callback is ignored and a warning is issued if both are > > > > > set. > > > > > > Why is that ? The two are distinct objects, why can't they both have a > > > release function ? > > > > You could, in principle, but in practice both of the structs are part of > > the same driver's device context struct which is a single allocation. You > > can only have a single release callback for it. > > If both release callbacks freed the same data structure, that would > indeed be a problem. There could be other use cases though. For > instance, in the uvcvideo driver, the top-level structure is > reference-counted, and the release callbacks of the video devices > decrement that reference count. I don't expect drivers to do something > similar with media_device and v4l2_device, but I'm not sure if we should > forbid it completely. If we do, I would then rather deprecate the > release callback of v4l2_device completely. There are quite a few drivers using the struct v4l2_device's release callback, it seems. We very probably can't get rid of it except possibly in the long term. The documentation already takes this into account, see patch "media: Documentation: Document how Media device resources are released". -- Regards, Sakari Ailus
