[PATCH 3/3] drm/qxl: Remove qxl_debugfs_remove_files()

Daniel Vetter daniel at ffwll.ch
Wed Mar 8 15:07:28 UTC 2017


On Wed, Mar 08, 2017 at 12:33:01PM +0100, Gerd Hoffmann wrote:
> On Mi, 2017-03-08 at 10:52 +0100, Daniel Vetter wrote:
> > On Wed, Mar 08, 2017 at 08:45:13AM +0100, Gerd Hoffmann wrote:
> > > On Di, 2017-03-07 at 21:49 +0100, Noralf Trønnes wrote:
> > > > drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> > > > automatically, so it's not necessary to call
> > > > drm_debugfs_remove_files().
> > > > 
> > > > Cc: airlied at linux.ie
> > > > Cc: kraxel at redhat.com
> > > > Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
> > > 
> > > Reviewed-by: Gerd Hoffmann <kraxel at redhat.com>
> > 
> > I assume you'll push to drm-misc yourself since its qxl?
> 
> Can surely do that.
> 
> Question though:  This seems to be a cross-driver cleanup series.  At
> least only 3/3 landed in my inbox, did't look @ dri-devel for the other
> patches.  What is the usual policy on those?
> 
> From the past I had the impression that in such a case the whole series
> gets applied by one of the drm-misc maintainers instead of each
> individual driver maintainer cherry-picking the patches from the
> series ...

Well mostly because many driver maintainers aren't dutiful with picking up
patches, or lose them again, or just take forever. But for this series
here there's no such excuse, and there's also no technical reason to order
patches a certain way (at least your qxl one is free standing and depends
upon nothing else and blocks nothing else).

One of my goals with drm-misc is that I can reduce my efforts spending on
catchging other maintainer's fallout, so I'd very much encourage everyone
to just push stuff. Especially if you're the maintainer, and you slap an
r-b onto a patch with no indication whether you merge it yourself or
except someone else to merge it it's confusing and just improves the odds
of the patch hitting one of our holes ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list