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. If that's not an issue, this patch seems fine, so Acked-by: Stephen Warren <swarren@xxxxxxxxxx> > 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
