On 07/30/2018 12:32 PM, Mikulas Patocka wrote: > The udlfb driver maintained an open count and cleaned up itself when the > count reached zero. But the console is also counted in the reference count > - so, if the user unplugged the device, the open count would not drop to > zero and the driver stayed loaded with console attached. If the user > re-plugged the adapter, it would create a device /dev/fb1, show green > screen and the access to the console would be lost. > > The framebuffer subsystem has reference counting on its own - in order to > fix the unplug bug, we rely the framebuffer reference counting. When the > user unplugs the adapter, we call unregister_framebuffer unconditionally. > unregister_framebuffer will unbind the console, wait until all users stop > using the framebuffer and then call the fb_destroy method. The fb_destroy > cleans up the USB driver. > > This patch makes the following changes: > * Drop dlfb->kref and rely on implicit framebuffer reference counting > instead. > * dlfb_usb_disconnect calls unregister_framebuffer, the rest of driver > cleanup is done in the function dlfb_ops_destroy. dlfb_ops_destroy will > be called by the framebuffer subsystem when no processes have the > framebuffer open or mapped. > * We don't use workqueue during initialization, but initialize directly > from dlfb_usb_probe. The workqueue could race with dlfb_usb_disconnect > and this racing would produce various kinds of memory corruption. > * We use usb_get_dev and usb_put_dev to make sure that the USB subsystem > doesn't free the device under us. > > Signed-off-by: Mikulas Patocka <mpatocka@xxxxxxxxxx> Patch queued for 4.20, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
