On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote: > > > > Den 27.01.2017 08.49, skrev Daniel Vetter: > > > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: > > > > This patchset removes the need for drivers to clean up their debugfs > > > > files on exit. It is done automatically in drm_debugfs_cleanup(). > > > > This funtion is also called should the driver error out in it's > > > > drm_driver.debugfs_init callback. > > > > > > > > Two drivers still use drm_debugfs_remove_files(): > > > > - tegra in it's connectors, not sure if I can remove it. > > > I read through them, and they're removed on the component device nodes > > > stuff. That looks somewhat fishy from a lifetime point of view, and I > > > think removing all that code would be better, too. > > > > > > > - qxl because it's debugfs files list is part of struct qxl_device which > > > > is freed on unload before drm_minor_unregister() is called cleaning debugfs. > > > In -next qxl is already demidlayered and there's no longer an unload hook. > > > This should be all safe ... why is it not? > > > > My bad, I fetched linux-next a few days ago and figured it was > > up-to-date-enough. Duh, I should have known better after following drm for > > a year now, it is constantly changing, no pauses. > > > > Can you please ping me when you have pulled driver patches and I'll respin > > msm, tegra and qxl (and others if necessary), and remove the hook. > > It's much easier for me to do a small patchset, it's really a strain to get > > everything lined up correctly with big changes. I didn't have that patch > > juggling class when in school, so I'm late to the game :-) > > You're doing great with the patch juggling :-) I've just made a pass > through the series and merge what's already reviewed/acked. Ok, pulled in the remaining patch (I hope, pls ping if I missed one). We have only a few debugfs_remove calls left, and I think it's safe to remove them all too. Up to do that too? Then we could remove the export, to make sure no new driver gets this wrong ... Thanks a lot, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
