Messages in this thread | | | Date | Wed, 02 Oct 2013 10:16:34 -0600 | From | Stephen Warren <> | Subject | Re: [PATCH 1/2] simplefb: fix unmapping fb during destruction |
| |
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@nvidia.com>
> 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.
| |