Skip to content
  • Mikulas Patocka's avatar
    udlfb: handle unplug properly · 68a958a9
    Mikulas Patocka authored
    
    
    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: default avatarMikulas Patocka <mpatocka@redhat.com>
    cc: Dave Airlie <airlied@redhat.com>
    Cc: Bernie Thompson <bernie@plugable.com>,
    Cc: Ladislav Michl <ladis@linux-mips.org>
    Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    68a958a9