Thread (3 messages) 3 messages, 2 authors, 2011-06-06

Re: [Patch 2/2 resend] Prevent vga16fb from accessing hw after it

From: Bruno Prémont <bonbons@linux-vserver.org>
Date: 2011-06-06 20:08:51

On Mon, 06 June 2011 Paul Mundt [off-list ref] wrote:
On Tue, May 24, 2011 at 10:32:21PM +0200, Bruno Pr??mont wrote:
quoted
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 5aac00e..bd9f93b 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1661,6 +1661,11 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
 	device_destroy(fb_class, MKDEV(FB_MAJOR, i));
 	event.info = fb_info;
 	fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
+	if (fb_info->fbops->fb_unregistered) {
+		mutex_lock(&fb_info->lock);
+		fb_info->fbops->fb_unregistered(fb_info);
+		mutex_unlock(&fb_info->lock);
+	}
 
 	/* this may free fb info */
 	put_fb_info(fb_info);
I'm not sure I really see the point, given that you can already do all of
the same work by tying in to the notifier chain. See for example the
sh_mobile_hdmi driver and its unreg notifier.
You can but is it a good idea to hook the driver itself to notifier chain
and do the work to find out if the info it's being notified for is one it
cares about?

In addition, if driver gets informed via the notifier it's unknown if kernel
users or driver get notified first, thus fb driver cannot give all kernel
users opportunity to cleanup before cleaning-up itself.
At best notification order depends on loading order of modules for fb driver
and kernel fb user (like fbcon).

Bruno
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help