Hi On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 10/02/2013 08:58 AM, David Herrmann wrote: >> Unfortunately, fbdev does not create its own "struct device" for >> framebuffers. Instead, it attaches to the device of the parent layer. This >> has the side-effect that devm_* managed resources are not cleaned up on >> framebuffer-destruction but rather during destruction of the >> parent-device. In case of fbdev this might be too late, though. >> remove_conflicting_framebuffer() may remove fbdev devices but keep the >> parent device as it is. >> >> Therefore, we now use plain ioremap() and unmap the framebuffer in the >> fb_destroy() callback. Note that we must not free the device here as this >> might race with the parent-device removal. Instead, we rely on >> unregister_framebuffer() as barrier and we're safe. > > So, once the .fb_destroy callback has been executed, there's no other > callback to resurrect it? The framebuffer itself is still registered > until the device's remove, yet after .fb_destroy, the memory is > unmapped, which would be dangerous if the FB can be re-started. fbdev lifetime tracking is weird.. ->fb_destroy() is called by unregister_framebuffer() _after_ it got unlinked. So no, the framebuffer is gone and cannot be resurrected. However, the unregistered/dead fbdev object itself stays around until you call framebuffer_release(). We cannot call it from fb_destroy(), though as the platform_data in your platform device still points to the fbdev device. Therefore we keep it and wait for the platform-driver to be removed which then again calls unregister_framebuffer() (which will immediately return as the fbdev device is not registered) and then you can finally call framebuffer_release(). Note that even though there's fb_get_info() and fb_put_info(), both are not exported and never used. So there is *no* fbdev ref-counting (which would be horribly broken anyway) and the driver is the sole owner of the fbdev object. > If that's not an issue, this patch seems fine, so > Acked-by: Stephen Warren <swarren@xxxxxxxxxx> Thanks! >> I know that simplefb was supposed to stay "as simple as possible" but I really >> think this series is the last set of fixes I have. Unfortunately framebuffer DRM >> handover is mandatory so we cannot ignore it in simplefb. > > I don't think this patch adds any significant complexity, so I'm not > worried at least. Good to hear! Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
