kernel/linux.git/drivers/gpu/drm/udl, branch v4.14.152

drm/udl: move to embedding drm device inside udl device.

2019-07-21T07:04:43+00:00

commit 6ecac85eadb9d4065b9038fa3d3c66d49038e14b upstream. This should help with some of the lifetime issues, and move us away from load/unload. [rez] Regarding the backport to v4.14.y, the only difference is due to the fact that in v4.14.y the udl_usb_probe() function still uses drm_dev_unref() instead of drm_dev_put(). Backport notes: On Mon, Jul 15, 2019 at 09:13:08PM -0400, Sasha Levin wrote: > Hm, we don't need ac3b35f11a06 here? Why not? I'd love to document that > with the backport. Nope, we don't need that patch in the v4.14 backport. In v4.19.y we have two functions, drm_dev_put() and drm_dev_unref(), which are aliases for one another (drm_dev_unref() just calls drm_dev_put()). drm_dev_unref() is the older of the two, and was introduced back in v4.0. drm_dev_put() was introduced in v4.15 with 9a96f55034e41 drm: introduce drm_dev_{get/put} functions and slowly callers were moved from the old name (_unref) to the new name (_put). The patch you mentioned, ac3b35f11a06, is one such patch where we are replacing a drm_dev_unref() call with a drm_dev_put() call. This doesn't have a functional change, but was necessary so that the third patch in the v4.19.y series I sent would apply cleanly. For the v4.14.y series, though, the drm_dev_put() function hasn't yet been defined and everyone is still using drm_dev_unref(). So, we don't need a backport of ac3b35f11a06, and I also had a small backport change in the last patch of the v4.14.y series where I had to change a drm_dev_put() call with a drm_dev_unref() call. Just for posterity, the drm_dev_unref() calls were eventually all changed to drm_dev_put() in v5.0, and drm_dev_unref() was removed entirely. That happened with the following two patches: 808bad32ea423 drm: replace "drm_dev_unref" function with "drm_dev_put" ba1d345401476 drm: remove deprecated "drm_dev_unref" function Acked-by: Alex Deucher Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-4-airlied@gmail.com Signed-off-by: Ross Zwisler Signed-off-by: Sasha Levin

drm/udl: introduce a macro to convert dev to udl.

2019-07-21T07:04:43+00:00

commit fd96e0dba19c53c2d66f2a398716bb74df8ca85e upstream. This just makes it easier to later embed drm into udl. [rez] Regarding the backport to v4.14.y, the only difference is due to the fact that in v4.14.y the udl_gem_mmap() function doesn't have a local 'struct udl_device' pointer so it didn't need to be converted. Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-3-airlied@gmail.com Signed-off-by: Ross Zwisler Signed-off-by: Sasha Levin

drm/udl: add a release method and delay modeset teardown

2019-04-17T06:37:52+00:00

commit 9b39b013037fbfa8d4b999345d9e904d8a336fc2 upstream. If we unplug a udl device, the usb callback with deinit the mode_config struct, however userspace will still have an open file descriptor and a framebuffer on that device. When userspace closes the fd, we'll oops because it'll try and look stuff up in the object idr which we've destroyed. This punts destroying the mode objects until release time instead. Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-2-airlied@gmail.com Signed-off-by: Greg Kroah-Hartman

drm: udl: Destroy framebuffer only if it was initialized

2018-09-29T10:06:05+00:00

commit fcb74da1eb8edd3a4ef9b9724f88ed709d684227 upstream. This fixes a NULL pointer dereference that can happen if the UDL driver is unloaded before the framebuffer is initialized. This can happen e.g. if the USB device is unplugged right after it was plugged in. As explained by Stéphane Marchesin: It happens when fbdev is disabled (which is the case for Chrome OS). Even though intialization of the fbdev part is optional (it's done in udlfb_create which is the callback for fb_probe()), the teardown isn't optional (udl_driver_unload -> udl_fbdev_cleanup -> udl_fbdev_destroy). Note that udl_fbdev_cleanup *tries* to be conditional (you can see it does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is always set during udl_fbdev_init. Cc: stable@vger.kernel.org Suggested-by: Sean Paul Reviewed-by: Sean Paul Acked-by: Daniel Vetter Signed-off-by: Emil Lundmark Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20180528142711.142466-1-lndmrk@chromium.org Signed-off-by: Sean Paul Signed-off-by: Greg Kroah-Hartman

udl-kms: avoid division

2018-09-05T07:26:38+00:00

commit 91ba11fb7d7ca0a3bbe8a512e65e666e2ec1e889 upstream. Division is slow, so it shouldn't be done by the pixel generating code. The driver supports only 2 or 4 bytes per pixel, so we can replace division with a shift. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

udl-kms: fix crash due to uninitialized memory

2018-09-05T07:26:38+00:00

commit 09a00abe3a9941c2715ca83eb88172cd2f54d8fd upstream. We must use kzalloc when allocating the fb_deferred_io structure. Otherwise, the field first_io is undefined and it causes a crash. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

udl-kms: handle allocation failure

2018-09-05T07:26:38+00:00

commit 542bb9788a1f485eb1a2229178f665d8ea166156 upstream. Allocations larger than PAGE_ALLOC_COSTLY_ORDER are unreliable and they may fail anytime. This patch fixes the udl kms driver so that when a large alloactions fails, it tries to do multiple smaller allocations. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

udl-kms: change down_interruptible to down

2018-09-05T07:26:38+00:00

commit 8456b99c16d193c4c3b7df305cf431e027f0189c upstream. If we leave urbs around, it causes not only leak, but also memory corruption. This patch fixes the function udl_free_urb_list, so that it always waits for all urbs that are in progress. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/udl: fix display corruption of the last line

2018-07-11T14:29:16+00:00

commit 99ec9e77511dea55d81729fc80b6c63a61bfa8e0 upstream. The displaylink hardware has such a peculiarity that it doesn't render a command until next command is received. This produces occasional corruption, such as when setting 22x11 font on the console, only the first line of the cursor will be blinking if the cursor is located at some specific columns. When we end up with a repeating pixel, the driver has a bug that it leaves one uninitialized byte after the command (and this byte is enough to flush the command and render it - thus it fixes the screen corruption), however whe we end up with a non-repeating pixel, there is no byte appended and this results in temporary screen corruption. This patch fixes the screen corruption by always appending a byte 0xAF at the end of URB. It also removes the uninitialized byte. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm: udl: Properly check framebuffer mmap offsets

2018-03-28T16:24:40+00:00

commit 3b82a4db8eaccce735dffd50b4d4e1578099b8e8 upstream. The memmap options sent to the udl framebuffer driver were not being checked for all sets of possible crazy values. Fix this up by properly bounding the allowed values. Reported-by: Eyal Itkin Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180321154553.GA18454@kroah.com Signed-off-by: Greg Kroah-Hartman