All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	rodrigo.vivi@intel.com, tvrtko.ursulin@linux.intel.com,
	ville.syrjala@linux.intel.com, imre.deak@intel.com,
	tejas.upadhyay@intel.com, airlied@gmail.com, daniel@ffwll.ch
Cc: intel-gfx@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 2/7] drm/client: Do not acquire module reference
Date: Wed, 01 Nov 2023 13:01:12 +0100	[thread overview]
Message-ID: <87bkcdhed3.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20230927102808.18650-3-tzimmermann@suse.de>

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Do not acquire a reference on the module that provides a client's
> callback functions in drm_client_init(). The additional reference
> prevents the user from unloading the callback functions' module and
> thus creating dangling pointers.
>
> This is only necessary if there is no direct dependency between the
> caller of drm_client_init() and the provider of the callbacks in
> struct drm_client_funcs. If this case ever existed, it has been
> removed from the DRM code. Callers of drm_client_init() also provide
> the callback implementation. The lifetime of the clients is tied to
> the dependency chain's outer-most module, which is the hardware's
> DRM driver. Before client helpers could be unloaded, the driver module
> would have to be unloaded, which also unregisters all clients.
>
> Driver modules that set up DRM clients can now be unloaded.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---

The change makes sense to me.

Acked-by: Javier Martinez Canillas <javierm@redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	rodrigo.vivi@intel.com, tvrtko.ursulin@linux.intel.com,
	ville.syrjala@linux.intel.com, imre.deak@intel.com,
	tejas.upadhyay@intel.com, airlied@gmail.com, daniel@ffwll.ch
Cc: intel-gfx@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 2/7] drm/client: Do not acquire module reference
Date: Wed, 01 Nov 2023 13:01:12 +0100	[thread overview]
Message-ID: <87bkcdhed3.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20230927102808.18650-3-tzimmermann@suse.de>

Thomas Zimmermann <tzimmermann@suse.de> writes:

> Do not acquire a reference on the module that provides a client's
> callback functions in drm_client_init(). The additional reference
> prevents the user from unloading the callback functions' module and
> thus creating dangling pointers.
>
> This is only necessary if there is no direct dependency between the
> caller of drm_client_init() and the provider of the callbacks in
> struct drm_client_funcs. If this case ever existed, it has been
> removed from the DRM code. Callers of drm_client_init() also provide
> the callback implementation. The lifetime of the clients is tied to
> the dependency chain's outer-most module, which is the hardware's
> DRM driver. Before client helpers could be unloaded, the driver module
> would have to be unloaded, which also unregisters all clients.
>
> Driver modules that set up DRM clients can now be unloaded.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---

The change makes sense to me.

Acked-by: Javier Martinez Canillas <javierm@redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


  reply	other threads:[~2023-11-01 12:01 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 10:26 [Intel-gfx] [PATCH v5 0/7] drm/i915: Convert fbdev to DRM client Thomas Zimmermann
2023-09-27 10:26 ` Thomas Zimmermann
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 1/7] drm/i915: Unregister in-kernel clients Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-10-25  7:28   ` [Intel-gfx] " Hogander, Jouni
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 2/7] drm/client: Do not acquire module reference Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-11-01 12:01   ` Javier Martinez Canillas [this message]
2023-11-01 12:01     ` Javier Martinez Canillas
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 3/7] drm/client: Export drm_client_dev_unregister() Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 4/7] drm/i915: Move fbdev functions Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-10-25  7:49   ` [Intel-gfx] " Hogander, Jouni
2023-10-25  7:49     ` Hogander, Jouni
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 5/7] drm/i915: Initialize fbdev DRM client with callback functions Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-10-25  8:36   ` [Intel-gfx] " Hogander, Jouni
2023-11-01  8:11     ` Thomas Zimmermann
2023-11-01  9:10       ` Hogander, Jouni
2023-11-01  9:32         ` Thomas Zimmermann
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 6/7] drm/i915: Implement fbdev client callbacks Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-10-25  9:36   ` [Intel-gfx] " Hogander, Jouni
2023-11-01  8:26     ` Thomas Zimmermann
2023-09-27 10:26 ` [Intel-gfx] [PATCH v5 7/7] drm/i915: Implement fbdev emulation as in-kernel client Thomas Zimmermann
2023-09-27 10:26   ` Thomas Zimmermann
2023-10-25 11:36   ` [Intel-gfx] " Hogander, Jouni
2023-10-25 11:36     ` Hogander, Jouni
2023-11-01  8:33     ` [Intel-gfx] " Thomas Zimmermann
2023-11-01  8:33       ` Thomas Zimmermann
2023-11-01  9:25       ` [Intel-gfx] " Ville Syrjälä
2023-11-01  9:25         ` Ville Syrjälä
2023-11-01  9:35         ` [Intel-gfx] " Thomas Zimmermann
2023-11-01  9:35           ` Thomas Zimmermann
2023-09-27 18:52 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Convert fbdev to DRM client (rev5) Patchwork
2023-09-27 19:06 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-09-28  7:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=87bkcdhed3.fsf@minerva.mail-host-address-is-not-set \
    --to=javierm@redhat.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=tejas.upadhyay@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@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 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.