From: Sam Ravnborg <sam@ravnborg.org> To: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>, Marco Felsch <m.felsch@pengutronix.de>, DRI Development <dri-devel@lists.freedesktop.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Daniel Vetter <daniel.vetter@intel.com> Subject: Re: [PATCH 03/51] drm: add managed resources tied to drm_device Date: Sat, 29 Feb 2020 12:17:10 +0100 [thread overview] Message-ID: <20200229111710.GB3674@ravnborg.org> (raw) In-Reply-To: <CAKMK7uHPWZ=F2EyqnM7x1GpXY_SGu3e_jGXX4cg0OGyx_+C8ig@mail.gmail.com> Hi Daniel. > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > index 9fcd6ab3c154..3e5627d6eba6 100644 > > > --- a/drivers/gpu/drm/drm_drv.c > > > +++ b/drivers/gpu/drm/drm_drv.c > > > @@ -629,6 +629,9 @@ int drm_dev_init(struct drm_device *dev, > > > dev->dev = get_device(parent); > > > dev->driver = driver; > > > > > > + INIT_LIST_HEAD(&dev->managed.resources); > > > + spin_lock_init(&dev->managed.lock); > > > + > > > /* no per-device feature limits by default */ > > > dev->driver_features = ~0u; > > > > > > @@ -828,8 +831,16 @@ static void drm_dev_release(struct kref *ref) > > > dev->driver->release(dev); > > > } else { > > > drm_dev_fini(dev); > > > - kfree(dev); > > > + if (!dev->managed.final_kfree) { > > > + WARN_ON(!list_empty(&dev->managed.resources)); > > > + kfree(dev); > > > + } > > > > This looks sub-optimal. > > We cannot be sure a driver have used drmm_add_final_kfree() if it makes > > use of drmm_. > > So we may not WARN in all relavant cases. > > Also, we cannot expect all drivers that uses devmm_ to have managed > > to get rid of their ->release call-back. > > The above is purely transition code. It gets cleaned up once all > drivers call drmm_add_final_kfree(). This all disappears again, but > indeed looks like the interim state isn't quite what we want. > > > So the right thing looks to me like we should move it out to be > > unconditional. Se we will WARN_ON(!list_empty(&dev->managed.resources)) > > always. > > Until the driver has set drmm_add_final_kfree it's actually dangerous > to use the drmm stuff. Exactly because of the use-after-free you point > out below. Hence the warning to make sure there's no release actions. > I'll shuffle this around to make sure we call kfree last for all > possible paths and make sure this bisects all correctly. I was just reviewing the code I had on hand, and did not look further in the set of patches. Very good if we can keep is bisectable. > > > + * > > > + * Based on drivers/base/devres.c > > > + */ > > > + > > > +#include <drm/drm_managed.h> > > > + > > > +#include <linux/list.h> > > > +#include <linux/slab.h> > > > +#include <linux/spinlock.h> > > > + > > > +#include <drm/drm_device.h> > > > +#include <drm/drm_print.h> > > > > It is good practice to group the include files. > > And drm/ comes after linux/ > > I try to put the main header first to make sure it's stand-alone, but > I guess that works with the header check now? Do I need to do anything > to get that checked? The header-check infrastructure was dropped again - see: fcbb8461fd2376ba3782b5b8bd440c929b8e4980 So including it as the first header in the implmentation file is likely the best way to keep it self contained. We will spot errors sooner. > > > +static __always_inline struct drmres * alloc_dr(drmres_release_t release, > > > + size_t size, gfp_t gfp, int nid) > > Why do we force the compiler to inline this? > > Seems a little agressive. > > It's not for performance, but for kmalloc_trace_caller. No point if > our caller is always some boring function from drm_managed.c that > calls alloc_dr. If we force alloc_dr to inline, then we get the caller > of the drm_managed.c function traced as allocator. Much better. > > (I stole that trick from devres.c) > > I'll add a comment to explain this. Thanks. > > > All the two users so far uses dev_to_node(dev->dev) for the nid. > > Maybe let this function take a drm_device * and thus move the > > calculation to this function? > > Copypastes like that :-) I feel somewhat meh here ... Well - keep the diff for devres smaller for now and leave it. It was just an observation. > > > + /** > > > + * @managed: > > > + * > > > + * Managed resources linked to the lifetime of this &drm_device as > > > + * tracked by @ref. > > > + */ > > > + struct { > > > + struct list_head resources; > > > + void *final_kfree; > > > + spinlock_t lock; > > > + } managed; > > > > I am missing kernel-doc here. > > At least document that lock is used to guard access to resources. > > (s/lock/lock_resources/ ?) > > Dunno why, but the support for name sub-structures seems to have > broken in kerneldoc. So I can type it, but it's not showing up, so I > didn't bother. Well I had it, but deleted it again. It's still > documented to work, but I have no idea what I'm doing wrong. Most readers prefer the .c files as the source. I personally read the generated kernel doc when I google and when I check that my own stuff looks good in kernel-doc format. So comments are still valueable despite not being picked up by kernel-doc. You know this - but I just wanted to encourage you to write the few lines that may help me and others :-) Sam _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org> To: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>, Marco Felsch <m.felsch@pengutronix.de>, DRI Development <dri-devel@lists.freedesktop.org>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Daniel Vetter <daniel.vetter@intel.com> Subject: Re: [Intel-gfx] [PATCH 03/51] drm: add managed resources tied to drm_device Date: Sat, 29 Feb 2020 12:17:10 +0100 [thread overview] Message-ID: <20200229111710.GB3674@ravnborg.org> (raw) In-Reply-To: <CAKMK7uHPWZ=F2EyqnM7x1GpXY_SGu3e_jGXX4cg0OGyx_+C8ig@mail.gmail.com> Hi Daniel. > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > index 9fcd6ab3c154..3e5627d6eba6 100644 > > > --- a/drivers/gpu/drm/drm_drv.c > > > +++ b/drivers/gpu/drm/drm_drv.c > > > @@ -629,6 +629,9 @@ int drm_dev_init(struct drm_device *dev, > > > dev->dev = get_device(parent); > > > dev->driver = driver; > > > > > > + INIT_LIST_HEAD(&dev->managed.resources); > > > + spin_lock_init(&dev->managed.lock); > > > + > > > /* no per-device feature limits by default */ > > > dev->driver_features = ~0u; > > > > > > @@ -828,8 +831,16 @@ static void drm_dev_release(struct kref *ref) > > > dev->driver->release(dev); > > > } else { > > > drm_dev_fini(dev); > > > - kfree(dev); > > > + if (!dev->managed.final_kfree) { > > > + WARN_ON(!list_empty(&dev->managed.resources)); > > > + kfree(dev); > > > + } > > > > This looks sub-optimal. > > We cannot be sure a driver have used drmm_add_final_kfree() if it makes > > use of drmm_. > > So we may not WARN in all relavant cases. > > Also, we cannot expect all drivers that uses devmm_ to have managed > > to get rid of their ->release call-back. > > The above is purely transition code. It gets cleaned up once all > drivers call drmm_add_final_kfree(). This all disappears again, but > indeed looks like the interim state isn't quite what we want. > > > So the right thing looks to me like we should move it out to be > > unconditional. Se we will WARN_ON(!list_empty(&dev->managed.resources)) > > always. > > Until the driver has set drmm_add_final_kfree it's actually dangerous > to use the drmm stuff. Exactly because of the use-after-free you point > out below. Hence the warning to make sure there's no release actions. > I'll shuffle this around to make sure we call kfree last for all > possible paths and make sure this bisects all correctly. I was just reviewing the code I had on hand, and did not look further in the set of patches. Very good if we can keep is bisectable. > > > + * > > > + * Based on drivers/base/devres.c > > > + */ > > > + > > > +#include <drm/drm_managed.h> > > > + > > > +#include <linux/list.h> > > > +#include <linux/slab.h> > > > +#include <linux/spinlock.h> > > > + > > > +#include <drm/drm_device.h> > > > +#include <drm/drm_print.h> > > > > It is good practice to group the include files. > > And drm/ comes after linux/ > > I try to put the main header first to make sure it's stand-alone, but > I guess that works with the header check now? Do I need to do anything > to get that checked? The header-check infrastructure was dropped again - see: fcbb8461fd2376ba3782b5b8bd440c929b8e4980 So including it as the first header in the implmentation file is likely the best way to keep it self contained. We will spot errors sooner. > > > +static __always_inline struct drmres * alloc_dr(drmres_release_t release, > > > + size_t size, gfp_t gfp, int nid) > > Why do we force the compiler to inline this? > > Seems a little agressive. > > It's not for performance, but for kmalloc_trace_caller. No point if > our caller is always some boring function from drm_managed.c that > calls alloc_dr. If we force alloc_dr to inline, then we get the caller > of the drm_managed.c function traced as allocator. Much better. > > (I stole that trick from devres.c) > > I'll add a comment to explain this. Thanks. > > > All the two users so far uses dev_to_node(dev->dev) for the nid. > > Maybe let this function take a drm_device * and thus move the > > calculation to this function? > > Copypastes like that :-) I feel somewhat meh here ... Well - keep the diff for devres smaller for now and leave it. It was just an observation. > > > + /** > > > + * @managed: > > > + * > > > + * Managed resources linked to the lifetime of this &drm_device as > > > + * tracked by @ref. > > > + */ > > > + struct { > > > + struct list_head resources; > > > + void *final_kfree; > > > + spinlock_t lock; > > > + } managed; > > > > I am missing kernel-doc here. > > At least document that lock is used to guard access to resources. > > (s/lock/lock_resources/ ?) > > Dunno why, but the support for name sub-structures seems to have > broken in kerneldoc. So I can type it, but it's not showing up, so I > didn't bother. Well I had it, but deleted it again. It's still > documented to work, but I have no idea what I'm doing wrong. Most readers prefer the .c files as the source. I personally read the generated kernel doc when I google and when I check that my own stuff looks good in kernel-doc format. So comments are still valueable despite not being picked up by kernel-doc. You know this - but I just wanted to encourage you to write the few lines that may help me and others :-) Sam _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-02-29 11:17 UTC|newest] Thread overview: 228+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-27 18:14 [PATCH 00/51] drm managed resources, v3 Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 01/51] mm/sl[uo]b: export __kmalloc_track(_node)_caller Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` Daniel Vetter 2020-02-27 18:14 ` [PATCH 02/51] drm/i915: Don't clear drvdata in ->release Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 03/51] drm: add managed resources tied to drm_device Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-28 22:45 ` Sam Ravnborg 2020-02-28 22:45 ` [Intel-gfx] " Sam Ravnborg 2020-02-28 23:14 ` Daniel Vetter 2020-02-28 23:14 ` [Intel-gfx] " Daniel Vetter 2020-02-29 11:17 ` Sam Ravnborg [this message] 2020-02-29 11:17 ` Sam Ravnborg 2020-02-29 11:28 ` Daniel Vetter 2020-02-29 11:28 ` [Intel-gfx] " Daniel Vetter 2020-03-02 9:22 ` Jani Nikula 2020-03-02 9:22 ` [Intel-gfx] " Jani Nikula 2020-03-02 9:36 ` Daniel Vetter 2020-03-02 9:36 ` [Intel-gfx] " Daniel Vetter 2020-03-02 9:36 ` Daniel Vetter 2020-03-02 9:39 ` Daniel Vetter 2020-03-02 9:39 ` [Intel-gfx] " Daniel Vetter 2020-03-02 16:34 ` Sam Ravnborg 2020-03-02 16:34 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:14 ` [PATCH 04/51] drm: Set final_kfree in drm_dev_alloc Daniel Vetter 2020-02-27 18:14 ` [Xen-devel] " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 05/51] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 20:55 ` Sam Ravnborg 2020-02-27 20:55 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:14 ` [PATCH 06/51] drm/udl: Use drmm_add_final_kfree Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 20:57 ` Sam Ravnborg 2020-02-27 20:57 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:14 ` [PATCH 07/51] drm/qxl: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` Daniel Vetter 2020-02-27 18:14 ` [PATCH 08/51] drm/i915: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 09/51] drm/cirrus: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` Daniel Vetter 2020-02-27 21:01 ` Sam Ravnborg 2020-02-27 21:01 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 21:01 ` Sam Ravnborg 2020-02-27 18:14 ` [PATCH 10/51] drm/v3d: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 11/51] drm/tidss: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 12/51] drm/mcde: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 13/51] drm/vgem: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 21:02 ` Sam Ravnborg 2020-02-27 21:02 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:14 ` [PATCH 14/51] drm/vkms: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:59 ` Rodrigo Siqueira 2020-02-27 18:59 ` [Intel-gfx] " Rodrigo Siqueira 2020-02-27 18:14 ` [PATCH 15/51] drm/repaper: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 16/51] drm/inigenic: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-03-02 20:12 ` Paul Cercueil 2020-03-02 20:12 ` [Intel-gfx] " Paul Cercueil 2020-02-27 18:14 ` [PATCH 17/51] drm/gm12u320: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 18/51] drm/<drivers>: " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:35 ` Liviu Dudau 2020-02-27 18:35 ` [Intel-gfx] " Liviu Dudau 2020-02-27 18:14 ` [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 20/51] drm: Handle dev->unique with drmm_ Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 21/51] drm: Use drmm_ for drm_dev_init cleanup Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 22/51] drm: manage drm_minor cleanup with drmm_ Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 23/51] drm: Manage drm_gem_init " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 24/51] drm: Manage drm_vblank_cleanup " Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 25/51] drm: Garbage collect drm_dev_fini Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 26/51] drm: Manage drm_mode_config_init with drmm_ Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-28 7:30 ` Thomas Zimmermann 2020-02-28 7:30 ` [Intel-gfx] " Thomas Zimmermann 2020-02-28 8:43 ` Daniel Vetter 2020-02-28 8:43 ` [Intel-gfx] " Daniel Vetter 2020-02-28 9:56 ` Thomas Zimmermann 2020-02-28 9:56 ` [Intel-gfx] " Thomas Zimmermann 2020-02-28 20:26 ` Sam Ravnborg 2020-02-28 20:26 ` [Intel-gfx] " Sam Ravnborg 2020-02-28 23:11 ` Daniel Vetter 2020-02-28 23:11 ` [Intel-gfx] " Daniel Vetter 2020-02-29 10:59 ` Sam Ravnborg 2020-02-29 10:59 ` [Intel-gfx] " Sam Ravnborg 2020-03-02 14:09 ` Daniel Vetter 2020-03-02 14:09 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 27/51] drm/bochs: Remove leftover drm_atomic_helper_shutdown Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` [PATCH 28/51] drm/bochs: Drop explicit drm_mode_config_cleanup Daniel Vetter 2020-02-27 18:14 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:14 ` Daniel Vetter 2020-02-27 18:15 ` [PATCH 29/51] drm/cirrus: Drop explicit drm_mode_config_cleanup call Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-28 20:32 ` Sam Ravnborg 2020-02-28 20:32 ` [Intel-gfx] " Sam Ravnborg 2020-02-28 20:32 ` Sam Ravnborg 2020-02-27 18:15 ` [PATCH 30/51] drm/cirrus: Fully embrace devm_ Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-27 18:15 ` [PATCH 31/51] drm/ingenic: Drop explicit drm_mode_config_cleanup call Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-03-02 20:13 ` Paul Cercueil 2020-03-02 20:13 ` [Intel-gfx] " Paul Cercueil 2020-02-27 18:15 ` [PATCH 32/51] drm/mcde: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 33/51] drm/mcde: More devm_drm_dev_init Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 34/51] drm/meson: Drop explicit drm_mode_config_cleanup call Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-27 18:15 ` [PATCH 35/51] drm/pl111: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 36/51] drm/rcar-du: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-27 18:15 ` [PATCH 37/51] drm/rockchip: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-28 21:19 ` kbuild test robot 2020-02-28 21:19 ` kbuild test robot 2020-02-28 21:19 ` [Intel-gfx] " kbuild test robot 2020-02-28 21:19 ` kbuild test robot 2020-02-28 21:19 ` kbuild test robot 2020-02-28 23:34 ` Daniel Vetter 2020-02-28 23:34 ` Daniel Vetter 2020-02-28 23:34 ` [Intel-gfx] " Daniel Vetter 2020-02-28 23:34 ` Daniel Vetter 2020-02-28 23:34 ` Daniel Vetter 2020-02-29 1:53 ` kbuild test robot 2020-02-29 1:53 ` kbuild test robot 2020-02-29 1:53 ` [Intel-gfx] " kbuild test robot 2020-02-29 1:53 ` kbuild test robot 2020-02-29 1:53 ` kbuild test robot 2020-02-27 18:15 ` [PATCH 38/51] drm/stm: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-27 18:15 ` [PATCH 39/51] drm/shmob: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` Daniel Vetter 2020-02-27 18:15 ` [PATCH 40/51] drm/mtk: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 41/51] drm/tidss: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 42/51] drm/gm12u320: More drmm_ Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 43/51] drm/gm12u320: Use devm_drm_dev_init Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 44/51] drm/gm12u320: Use helpers for shutdown/suspend/resume Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 45/51] drm/gm12u320: Simplify upload work Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 19:04 ` Hans de Goede 2020-02-27 19:04 ` [Intel-gfx] " Hans de Goede 2020-02-27 18:15 ` [PATCH 46/51] drm/repaper: Drop explicit drm_mode_config_cleanup call Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 47/51] drm/mipi-dbi: Move drm_mode_config_init into mipi library Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-28 20:34 ` Sam Ravnborg 2020-02-28 20:34 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:15 ` [PATCH 48/51] drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-28 20:36 ` Sam Ravnborg 2020-02-28 20:36 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:15 ` [PATCH 49/51] drm/udl: " Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-28 20:37 ` Sam Ravnborg 2020-02-28 20:37 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 18:15 ` [PATCH 50/51] drm/udl: drop drm_driver.release hook Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-28 7:43 ` Thomas Zimmermann 2020-02-28 7:43 ` [Intel-gfx] " Thomas Zimmermann 2020-02-28 8:40 ` Daniel Vetter 2020-02-28 8:40 ` [Intel-gfx] " Daniel Vetter 2020-02-28 11:46 ` Thomas Zimmermann 2020-02-28 11:46 ` [Intel-gfx] " Thomas Zimmermann 2020-02-28 17:43 ` Daniel Vetter 2020-02-28 17:43 ` [Intel-gfx] " Daniel Vetter 2020-03-02 8:14 ` Thomas Zimmermann 2020-03-02 8:14 ` [Intel-gfx] " Thomas Zimmermann 2020-03-02 9:01 ` Daniel Vetter 2020-03-02 9:01 ` [Intel-gfx] " Daniel Vetter 2020-02-27 18:15 ` [PATCH 51/51] drm: Add docs for managed resources Daniel Vetter 2020-02-27 18:15 ` [Intel-gfx] " Daniel Vetter 2020-02-27 20:53 ` Sam Ravnborg 2020-02-27 20:53 ` [Intel-gfx] " Sam Ravnborg 2020-02-27 22:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm managed resources, v3 Patchwork 2020-02-27 22:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2020-02-27 23:08 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2020-02-29 5:27 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork -- strict thread matches above, loose matches on Subject: below -- 2020-03-23 14:48 [PATCH 00/51] drm_device managed resources, v5 Daniel Vetter 2020-03-23 14:49 ` [PATCH 03/51] drm: add managed resources tied to drm_device Daniel Vetter 2020-03-23 18:36 ` Sam Ravnborg 2020-03-02 22:25 [PATCH 00/51] drm_device managed resources, v4 Daniel Vetter 2020-03-02 22:25 ` [PATCH 03/51] drm: add managed resources tied to drm_device Daniel Vetter 2020-03-03 8:04 ` Dan Carpenter 2020-03-03 8:04 ` Dan Carpenter 2020-03-03 8:04 ` Dan Carpenter 2020-03-03 8:25 ` Daniel Vetter 2020-03-03 8:25 ` Daniel Vetter 2020-03-11 9:07 ` Thomas Zimmermann 2020-03-11 9:47 ` Thomas Zimmermann 2020-03-16 8:45 ` Daniel Vetter 2020-03-11 9:14 ` Thomas Zimmermann 2020-03-16 8:50 ` Daniel Vetter 2020-02-21 21:02 [PATCH 00/51] drm managed resources, v2 Daniel Vetter 2020-02-21 21:02 ` [PATCH 03/51] drm: add managed resources tied to drm_device Daniel Vetter 2020-02-25 10:27 ` Andrzej Hajda 2020-02-25 15:03 ` Daniel Vetter 2020-02-26 9:21 ` Andrzej Hajda 2020-02-26 10:21 ` Daniel Vetter 2020-02-26 14:38 ` Andrzej Hajda
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=20200229111710.GB3674@ravnborg.org \ --to=sam@ravnborg.org \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=m.felsch@pengutronix.de \ --cc=rafael@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: linkBe 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.