Den 01.03.2017 15.31, skrev Daniel Vetter:
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 ...
Yes, they're all in now. I'll fix up what's left.
Noralf.
Thanks a lot, Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
