From 805fa2adbf6c13c0d884cc10095c5760deea7f78 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 4 May 2020 11:12:47 +0200 Subject: [PATCH] 4.19-stable patches added patches: btrfs-fix-block-group-leak-when-removing-fails.patch btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch drm-qxl-qxl_release-use-after-free.patch mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch --- ...block-group-leak-when-removing-fails.patch | 95 ++++++++++++ ...alloc-extent-past-i_size-after-fsync.patch | 139 ++++++++++++++++++ ...ation-timing-of-fs_info-journal_info.patch | 127 ++++++++++++++++ ...off-by-one-in-dispid-dtd-pixel-clock.patch | 43 ++++++ ...xl_release-leak-in-qxl_draw_dirty_fb.patch | 37 +++++ ...release-leak-in-qxl_hw_surface_alloc.patch | 35 +++++ .../drm-qxl-qxl_release-use-after-free.patch | 115 +++++++++++++++ ...k-on-by-not-open-coding-timeout-loop.patch | 85 +++++++++++ ...-sdio-remove-the-broken-card_busy-op.patch | 67 +++++++++ ...-mx-sdio-set-mmc_cap_wait_while_busy.patch | 38 +++++ ...apabilities-pertains-to-r1b-response.patch | 42 ++++++ ...r-strength-for-byt-based-controllers.patch | 43 ++++++ ...-fix-annoying-1.8v-regulator-warning.patch | 58 ++++++++ queue-4.19/series | 13 ++ 14 files changed, 937 insertions(+) create mode 100644 queue-4.19/btrfs-fix-block-group-leak-when-removing-fails.patch create mode 100644 queue-4.19/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch create mode 100644 queue-4.19/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch create mode 100644 queue-4.19/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch create mode 100644 queue-4.19/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch create mode 100644 queue-4.19/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch create mode 100644 queue-4.19/drm-qxl-qxl_release-use-after-free.patch create mode 100644 queue-4.19/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch create mode 100644 queue-4.19/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch create mode 100644 queue-4.19/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch create mode 100644 queue-4.19/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch create mode 100644 queue-4.19/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch create mode 100644 queue-4.19/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch diff --git a/queue-4.19/btrfs-fix-block-group-leak-when-removing-fails.patch b/queue-4.19/btrfs-fix-block-group-leak-when-removing-fails.patch new file mode 100644 index 00000000000..fc7e8285b3e --- /dev/null +++ b/queue-4.19/btrfs-fix-block-group-leak-when-removing-fails.patch @@ -0,0 +1,95 @@ +From f6033c5e333238f299c3ae03fac8cc1365b23b77 Mon Sep 17 00:00:00 2001 +From: Xiyu Yang +Date: Tue, 21 Apr 2020 10:54:11 +0800 +Subject: btrfs: fix block group leak when removing fails + +From: Xiyu Yang + +commit f6033c5e333238f299c3ae03fac8cc1365b23b77 upstream. + +btrfs_remove_block_group() invokes btrfs_lookup_block_group(), which +returns a local reference of the block group that contains the given +bytenr to "block_group" with increased refcount. + +When btrfs_remove_block_group() returns, "block_group" becomes invalid, +so the refcount should be decreased to keep refcount balanced. + +The reference counting issue happens in several exception handling paths +of btrfs_remove_block_group(). When those error scenarios occur such as +btrfs_alloc_path() returns NULL, the function forgets to decrease its +refcnt increased by btrfs_lookup_block_group() and will cause a refcnt +leak. + +Fix this issue by jumping to "out_put_group" label and calling +btrfs_put_block_group() when those error scenarios occur. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Xiyu Yang +Signed-off-by: Xin Tan +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/extent-tree.c | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -10286,7 +10286,7 @@ int btrfs_remove_block_group(struct btrf + path = btrfs_alloc_path(); + if (!path) { + ret = -ENOMEM; +- goto out; ++ goto out_put_group; + } + + /* +@@ -10323,7 +10323,7 @@ int btrfs_remove_block_group(struct btrf + ret = btrfs_orphan_add(trans, BTRFS_I(inode)); + if (ret) { + btrfs_add_delayed_iput(inode); +- goto out; ++ goto out_put_group; + } + clear_nlink(inode); + /* One for the block groups ref */ +@@ -10346,13 +10346,13 @@ int btrfs_remove_block_group(struct btrf + + ret = btrfs_search_slot(trans, tree_root, &key, path, -1, 1); + if (ret < 0) +- goto out; ++ goto out_put_group; + if (ret > 0) + btrfs_release_path(path); + if (ret == 0) { + ret = btrfs_del_item(trans, tree_root, path); + if (ret) +- goto out; ++ goto out_put_group; + btrfs_release_path(path); + } + +@@ -10494,9 +10494,9 @@ int btrfs_remove_block_group(struct btrf + + ret = remove_block_group_free_space(trans, block_group); + if (ret) +- goto out; ++ goto out_put_group; + +- btrfs_put_block_group(block_group); ++ /* Once for the block groups rbtree */ + btrfs_put_block_group(block_group); + + ret = btrfs_search_slot(trans, root, &key, path, -1, 1); +@@ -10524,6 +10524,10 @@ int btrfs_remove_block_group(struct btrf + /* once for the tree */ + free_extent_map(em); + } ++ ++out_put_group: ++ /* Once for the lookup reference */ ++ btrfs_put_block_group(block_group); + out: + btrfs_free_path(path); + return ret; diff --git a/queue-4.19/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch b/queue-4.19/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch new file mode 100644 index 00000000000..3eede8f37a1 --- /dev/null +++ b/queue-4.19/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch @@ -0,0 +1,139 @@ +From f135cea30de5f74d5bfb5116682073841fb4af8f Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 23 Apr 2020 16:30:53 +0100 +Subject: btrfs: fix partial loss of prealloc extent past i_size after fsync + +From: Filipe Manana + +commit f135cea30de5f74d5bfb5116682073841fb4af8f upstream. + +When we have an inode with a prealloc extent that starts at an offset +lower than the i_size and there is another prealloc extent that starts at +an offset beyond i_size, we can end up losing part of the first prealloc +extent (the part that starts at i_size) and have an implicit hole if we +fsync the file and then have a power failure. + +Consider the following example with comments explaining how and why it +happens. + + $ mkfs.btrfs -f /dev/sdb + $ mount /dev/sdb /mnt + + # Create our test file with 2 consecutive prealloc extents, each with a + # size of 128Kb, and covering the range from 0 to 256Kb, with a file + # size of 0. + $ xfs_io -f -c "falloc -k 0 128K" /mnt/foo + $ xfs_io -c "falloc -k 128K 128K" /mnt/foo + + # Fsync the file to record both extents in the log tree. + $ xfs_io -c "fsync" /mnt/foo + + # Now do a redudant extent allocation for the range from 0 to 64Kb. + # This will merely increase the file size from 0 to 64Kb. Instead we + # could also do a truncate to set the file size to 64Kb. + $ xfs_io -c "falloc 0 64K" /mnt/foo + + # Fsync the file, so we update the inode item in the log tree with the + # new file size (64Kb). This also ends up setting the number of bytes + # for the first prealloc extent to 64Kb. This is done by the truncation + # at btrfs_log_prealloc_extents(). + # This means that if a power failure happens after this, a write into + # the file range 64Kb to 128Kb will not use the prealloc extent and + # will result in allocation of a new extent. + $ xfs_io -c "fsync" /mnt/foo + + # Now set the file size to 256K with a truncate and then fsync the file. + # Since no changes happened to the extents, the fsync only updates the + # i_size in the inode item at the log tree. This results in an implicit + # hole for the file range from 64Kb to 128Kb, something which fsck will + # complain when not using the NO_HOLES feature if we replay the log + # after a power failure. + $ xfs_io -c "truncate 256K" -c "fsync" /mnt/foo + +So instead of always truncating the log to the inode's current i_size at +btrfs_log_prealloc_extents(), check first if there's a prealloc extent +that starts at an offset lower than the i_size and with a length that +crosses the i_size - if there is one, just make sure we truncate to a +size that corresponds to the end offset of that prealloc extent, so +that we don't lose the part of that extent that starts at i_size if a +power failure happens. + +A test case for fstests follows soon. + +Fixes: 31d11b83b96f ("Btrfs: fix duplicate extents after fsync of file with prealloc extents") +CC: stable@vger.kernel.org # 4.14+ +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/tree-log.c | 43 ++++++++++++++++++++++++++++++++++++++++--- + 1 file changed, 40 insertions(+), 3 deletions(-) + +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -4182,6 +4182,9 @@ static int btrfs_log_prealloc_extents(st + const u64 ino = btrfs_ino(inode); + struct btrfs_path *dst_path = NULL; + bool dropped_extents = false; ++ u64 truncate_offset = i_size; ++ struct extent_buffer *leaf; ++ int slot; + int ins_nr = 0; + int start_slot; + int ret; +@@ -4196,9 +4199,43 @@ static int btrfs_log_prealloc_extents(st + if (ret < 0) + goto out; + ++ /* ++ * We must check if there is a prealloc extent that starts before the ++ * i_size and crosses the i_size boundary. This is to ensure later we ++ * truncate down to the end of that extent and not to the i_size, as ++ * otherwise we end up losing part of the prealloc extent after a log ++ * replay and with an implicit hole if there is another prealloc extent ++ * that starts at an offset beyond i_size. ++ */ ++ ret = btrfs_previous_item(root, path, ino, BTRFS_EXTENT_DATA_KEY); ++ if (ret < 0) ++ goto out; ++ ++ if (ret == 0) { ++ struct btrfs_file_extent_item *ei; ++ ++ leaf = path->nodes[0]; ++ slot = path->slots[0]; ++ ei = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item); ++ ++ if (btrfs_file_extent_type(leaf, ei) == ++ BTRFS_FILE_EXTENT_PREALLOC) { ++ u64 extent_end; ++ ++ btrfs_item_key_to_cpu(leaf, &key, slot); ++ extent_end = key.offset + ++ btrfs_file_extent_num_bytes(leaf, ei); ++ ++ if (extent_end > i_size) ++ truncate_offset = extent_end; ++ } ++ } else { ++ ret = 0; ++ } ++ + while (true) { +- struct extent_buffer *leaf = path->nodes[0]; +- int slot = path->slots[0]; ++ leaf = path->nodes[0]; ++ slot = path->slots[0]; + + if (slot >= btrfs_header_nritems(leaf)) { + if (ins_nr > 0) { +@@ -4236,7 +4273,7 @@ static int btrfs_log_prealloc_extents(st + ret = btrfs_truncate_inode_items(trans, + root->log_root, + &inode->vfs_inode, +- i_size, ++ truncate_offset, + BTRFS_EXTENT_DATA_KEY); + } while (ret == -EAGAIN); + if (ret) diff --git a/queue-4.19/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch b/queue-4.19/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch new file mode 100644 index 00000000000..0adec74cbd5 --- /dev/null +++ b/queue-4.19/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch @@ -0,0 +1,127 @@ +From fcc99734d1d4ced30167eb02e17f656735cb9928 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Mon, 27 Apr 2020 14:50:14 +0800 +Subject: btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info + +From: Qu Wenruo + +commit fcc99734d1d4ced30167eb02e17f656735cb9928 upstream. + +[BUG] +One run of btrfs/063 triggered the following lockdep warning: + ============================================ + WARNING: possible recursive locking detected + 5.6.0-rc7-custom+ #48 Not tainted + -------------------------------------------- + kworker/u24:0/7 is trying to acquire lock: + ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] + + but task is already holding lock: + ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] + + other info that might help us debug this: + Possible unsafe locking scenario: + + CPU0 + ---- + lock(sb_internal#2); + lock(sb_internal#2); + + *** DEADLOCK *** + + May be due to missing lock nesting notation + + 4 locks held by kworker/u24:0/7: + #0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80 + #1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80 + #2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs] + #3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs] + + stack backtrace: + CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 + Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] + Call Trace: + dump_stack+0xc2/0x11a + __lock_acquire.cold+0xce/0x214 + lock_acquire+0xe6/0x210 + __sb_start_write+0x14e/0x290 + start_transaction+0x66c/0x890 [btrfs] + btrfs_join_transaction+0x1d/0x20 [btrfs] + find_free_extent+0x1504/0x1a50 [btrfs] + btrfs_reserve_extent+0xd5/0x1f0 [btrfs] + btrfs_alloc_tree_block+0x1ac/0x570 [btrfs] + btrfs_copy_root+0x213/0x580 [btrfs] + create_reloc_root+0x3bd/0x470 [btrfs] + btrfs_init_reloc_root+0x2d2/0x310 [btrfs] + record_root_in_trans+0x191/0x1d0 [btrfs] + btrfs_record_root_in_trans+0x90/0xd0 [btrfs] + start_transaction+0x16e/0x890 [btrfs] + btrfs_join_transaction+0x1d/0x20 [btrfs] + btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs] + finish_ordered_fn+0x15/0x20 [btrfs] + btrfs_work_helper+0x116/0x9a0 [btrfs] + process_one_work+0x632/0xb80 + worker_thread+0x80/0x690 + kthread+0x1a3/0x1f0 + ret_from_fork+0x27/0x50 + +It's pretty hard to reproduce, only one hit so far. + +[CAUSE] +This is because we're calling btrfs_join_transaction() without re-using +the current running one: + +btrfs_finish_ordered_io() +|- btrfs_join_transaction() <<< Call #1 + |- btrfs_record_root_in_trans() + |- btrfs_reserve_extent() + |- btrfs_join_transaction() <<< Call #2 + +Normally such btrfs_join_transaction() call should re-use the existing +one, without trying to re-start a transaction. + +But the problem is, in btrfs_join_transaction() call #1, we call +btrfs_record_root_in_trans() before initializing current::journal_info. + +And in btrfs_join_transaction() call #2, we're relying on +current::journal_info to avoid such deadlock. + +[FIX] +Call btrfs_record_root_in_trans() after we have initialized +current::journal_info. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/transaction.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/transaction.c ++++ b/fs/btrfs/transaction.c +@@ -572,10 +572,19 @@ again: + } + + got_it: +- btrfs_record_root_in_trans(h, root); +- + if (!current->journal_info) + current->journal_info = h; ++ ++ /* ++ * btrfs_record_root_in_trans() needs to alloc new extents, and may ++ * call btrfs_join_transaction() while we're also starting a ++ * transaction. ++ * ++ * Thus it need to be called after current->journal_info initialized, ++ * or we can deadlock. ++ */ ++ btrfs_record_root_in_trans(h, root); ++ + return h; + + join_fail: diff --git a/queue-4.19/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch b/queue-4.19/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch new file mode 100644 index 00000000000..d0f876db96c --- /dev/null +++ b/queue-4.19/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch @@ -0,0 +1,43 @@ +From 6292b8efe32e6be408af364132f09572aed14382 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Thu, 23 Apr 2020 18:17:43 +0300 +Subject: drm/edid: Fix off-by-one in DispID DTD pixel clock +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 6292b8efe32e6be408af364132f09572aed14382 upstream. + +The DispID DTD pixel clock is documented as: +"00 00 00 h → FF FF FF h | Pixel clock ÷ 10,000 0.01 → 167,772.16 Mega Pixels per Sec" +Which seems to imply that we to add one to the raw value. + +Reality seems to agree as there are tiled displays in the wild +which currently show a 10kHz difference in the pixel clock +between the tiles (one tile gets its mode from the base EDID, +the other from the DispID block). + +Cc: stable@vger.kernel.org +References: https://gitlab.freedesktop.org/drm/intel/-/issues/27 +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20200423151743.18767-1-ville.syrjala@linux.intel.com +Reviewed-by: Manasi Navare +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_edid.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/drm_edid.c ++++ b/drivers/gpu/drm/drm_edid.c +@@ -4706,7 +4706,7 @@ static struct drm_display_mode *drm_mode + struct drm_display_mode *mode; + unsigned pixel_clock = (timings->pixel_clock[0] | + (timings->pixel_clock[1] << 8) | +- (timings->pixel_clock[2] << 16)); ++ (timings->pixel_clock[2] << 16)) + 1; + unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1; + unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1; + unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) + 1; diff --git a/queue-4.19/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch b/queue-4.19/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch new file mode 100644 index 00000000000..9a17be8e558 --- /dev/null +++ b/queue-4.19/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch @@ -0,0 +1,37 @@ +From 85e9b88af1e6164f19ec71381efd5e2bcfc17620 Mon Sep 17 00:00:00 2001 +From: Vasily Averin +Date: Mon, 27 Apr 2020 08:32:46 +0300 +Subject: drm/qxl: qxl_release leak in qxl_draw_dirty_fb() + +From: Vasily Averin + +commit 85e9b88af1e6164f19ec71381efd5e2bcfc17620 upstream. + +ret should be changed to release allocated struct qxl_release + +Cc: stable@vger.kernel.org +Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") +Signed-off-by: Vasily Averin +Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b7153c3d4@virtuozzo.com +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/qxl/qxl_draw.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/qxl/qxl_draw.c ++++ b/drivers/gpu/drm/qxl/qxl_draw.c +@@ -348,9 +348,10 @@ void qxl_draw_dirty_fb(struct qxl_device + goto out_release_backoff; + + rects = drawable_set_clipping(qdev, num_clips, clips_bo); +- if (!rects) ++ if (!rects) { ++ ret = -EINVAL; + goto out_release_backoff; +- ++ } + drawable = (struct qxl_drawable *)qxl_release_map(qdev, release); + + drawable->clip.type = SPICE_CLIP_TYPE_RECTS; diff --git a/queue-4.19/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch b/queue-4.19/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch new file mode 100644 index 00000000000..285e5aa6a43 --- /dev/null +++ b/queue-4.19/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch @@ -0,0 +1,35 @@ +From a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 Mon Sep 17 00:00:00 2001 +From: Vasily Averin +Date: Mon, 27 Apr 2020 08:32:51 +0300 +Subject: drm/qxl: qxl_release leak in qxl_hw_surface_alloc() + +From: Vasily Averin + +commit a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 upstream. + +Cc: stable@vger.kernel.org +Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") +Signed-off-by: Vasily Averin +Link: http://patchwork.freedesktop.org/patch/msgid/2e5a13ae-9ab2-5401-aa4d-03d5f5593423@virtuozzo.com +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/qxl/qxl_cmd.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/qxl/qxl_cmd.c ++++ b/drivers/gpu/drm/qxl/qxl_cmd.c +@@ -472,9 +472,10 @@ int qxl_hw_surface_alloc(struct qxl_devi + return ret; + + ret = qxl_release_reserve_list(release, true); +- if (ret) ++ if (ret) { ++ qxl_release_free(qdev, release); + return ret; +- ++ } + cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release); + cmd->type = QXL_SURFACE_CMD_CREATE; + cmd->flags = QXL_SURF_FLAG_KEEP_DATA; diff --git a/queue-4.19/drm-qxl-qxl_release-use-after-free.patch b/queue-4.19/drm-qxl-qxl_release-use-after-free.patch new file mode 100644 index 00000000000..629d2b1351e --- /dev/null +++ b/queue-4.19/drm-qxl-qxl_release-use-after-free.patch @@ -0,0 +1,115 @@ +From 933db73351d359f74b14f4af095808260aff11f9 Mon Sep 17 00:00:00 2001 +From: Vasily Averin +Date: Wed, 29 Apr 2020 12:01:24 +0300 +Subject: drm/qxl: qxl_release use after free + +From: Vasily Averin + +commit 933db73351d359f74b14f4af095808260aff11f9 upstream. + +qxl_release should not be accesses after qxl_push_*_ring_release() calls: +userspace driver can process submitted command quickly, move qxl_release +into release_ring, generate interrupt and trigger garbage collector. + +It can lead to crashes in qxl driver or trigger memory corruption +in some kmalloc-192 slab object + +Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() + +qxl_push_{cursor,command}_ring_release() calls to close that race window. + +cc: stable@vger.kernel.org +Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)") +Signed-off-by: Vasily Averin +Link: http://patchwork.freedesktop.org/patch/msgid/fa17b338-66ae-f299-68fe-8d32419d9071@virtuozzo.com +Signed-off-by: Gerd Hoffmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/qxl/qxl_cmd.c | 5 ++--- + drivers/gpu/drm/qxl/qxl_display.c | 6 +++--- + drivers/gpu/drm/qxl/qxl_draw.c | 2 +- + drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +---- + 4 files changed, 7 insertions(+), 11 deletions(-) + +--- a/drivers/gpu/drm/qxl/qxl_cmd.c ++++ b/drivers/gpu/drm/qxl/qxl_cmd.c +@@ -501,8 +501,8 @@ int qxl_hw_surface_alloc(struct qxl_devi + /* no need to add a release to the fence for this surface bo, + since it is only released when we ask to destroy the surface + and it would never signal otherwise */ +- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false); + qxl_release_fence_buffer_objects(release); ++ qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false); + + surf->hw_surf_alloc = true; + spin_lock(&qdev->surf_id_idr_lock); +@@ -544,9 +544,8 @@ int qxl_hw_surface_dealloc(struct qxl_de + cmd->surface_id = id; + qxl_release_unmap(qdev, release, &cmd->release_info); + +- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false); +- + qxl_release_fence_buffer_objects(release); ++ qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false); + + return 0; + } +--- a/drivers/gpu/drm/qxl/qxl_display.c ++++ b/drivers/gpu/drm/qxl/qxl_display.c +@@ -532,8 +532,8 @@ static int qxl_primary_apply_cursor(stru + cmd->u.set.visible = 1; + qxl_release_unmap(qdev, release, &cmd->release_info); + +- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + qxl_release_fence_buffer_objects(release); ++ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + + return ret; + +@@ -694,8 +694,8 @@ static void qxl_cursor_atomic_update(str + cmd->u.position.y = plane->state->crtc_y + fb->hot_y; + + qxl_release_unmap(qdev, release, &cmd->release_info); +- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + qxl_release_fence_buffer_objects(release); ++ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + + if (old_cursor_bo) + qxl_bo_unref(&old_cursor_bo); +@@ -740,8 +740,8 @@ static void qxl_cursor_atomic_disable(st + cmd->type = QXL_CURSOR_HIDE; + qxl_release_unmap(qdev, release, &cmd->release_info); + +- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + qxl_release_fence_buffer_objects(release); ++ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false); + } + + static int qxl_plane_prepare_fb(struct drm_plane *plane, +--- a/drivers/gpu/drm/qxl/qxl_draw.c ++++ b/drivers/gpu/drm/qxl/qxl_draw.c +@@ -382,8 +382,8 @@ void qxl_draw_dirty_fb(struct qxl_device + } + qxl_bo_kunmap(clips_bo); + +- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false); + qxl_release_fence_buffer_objects(release); ++ qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false); + + out_release_backoff: + if (ret) +--- a/drivers/gpu/drm/qxl/qxl_ioctl.c ++++ b/drivers/gpu/drm/qxl/qxl_ioctl.c +@@ -257,11 +257,8 @@ static int qxl_process_single_command(st + apply_surf_reloc(qdev, &reloc_info[i]); + } + ++ qxl_release_fence_buffer_objects(release); + ret = qxl_push_command_ring_release(qdev, release, cmd->type, true); +- if (ret) +- qxl_release_backoff_reserve_list(release); +- else +- qxl_release_fence_buffer_objects(release); + + out_free_bos: + out_free_release: diff --git a/queue-4.19/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch b/queue-4.19/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch new file mode 100644 index 00000000000..ba864faa7c2 --- /dev/null +++ b/queue-4.19/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch @@ -0,0 +1,85 @@ +From b1ac62a7ac386d76968af5f374a4a7a82a35fe31 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Mon, 13 Apr 2020 16:27:27 -0700 +Subject: mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop + +From: Douglas Anderson + +commit b1ac62a7ac386d76968af5f374a4a7a82a35fe31 upstream. + +Open-coding a timeout loop invariably leads to errors with handling +the timeout properly in one corner case or another. In the case of +cqhci we might report "CQE stuck on" even if it wasn't stuck on. +You'd just need this sequence of events to happen in cqhci_off(): + +1. Call ktime_get(). +2. Something happens to interrupt the CPU for > 100 us (context switch + or interrupt). +3. Check time and; set "timed_out" to true since > 100 us. +4. Read CQHCI_CTL. +5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break. +6. Since "timed_out" is true, falsely print the error message. + +Rather than fixing the polling loop, use readx_poll_timeout() like +many people do. This has been time tested to handle the corner cases. + +Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host") +Signed-off-by: Douglas Anderson +Acked-by: Adrian Hunter +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d030c6af8e0@changeid +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/cqhci.c | 21 ++++++++++----------- + 1 file changed, 10 insertions(+), 11 deletions(-) + +--- a/drivers/mmc/host/cqhci.c ++++ b/drivers/mmc/host/cqhci.c +@@ -13,6 +13,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -351,12 +352,16 @@ static int cqhci_enable(struct mmc_host + /* CQHCI is idle and should halt immediately, so set a small timeout */ + #define CQHCI_OFF_TIMEOUT 100 + ++static u32 cqhci_read_ctl(struct cqhci_host *cq_host) ++{ ++ return cqhci_readl(cq_host, CQHCI_CTL); ++} ++ + static void cqhci_off(struct mmc_host *mmc) + { + struct cqhci_host *cq_host = mmc->cqe_private; +- ktime_t timeout; +- bool timed_out; + u32 reg; ++ int err; + + if (!cq_host->enabled || !mmc->cqe_on || cq_host->recovery_halt) + return; +@@ -366,15 +371,9 @@ static void cqhci_off(struct mmc_host *m + + cqhci_writel(cq_host, CQHCI_HALT, CQHCI_CTL); + +- timeout = ktime_add_us(ktime_get(), CQHCI_OFF_TIMEOUT); +- while (1) { +- timed_out = ktime_compare(ktime_get(), timeout) > 0; +- reg = cqhci_readl(cq_host, CQHCI_CTL); +- if ((reg & CQHCI_HALT) || timed_out) +- break; +- } +- +- if (timed_out) ++ err = readx_poll_timeout(cqhci_read_ctl, cq_host, reg, ++ reg & CQHCI_HALT, 0, CQHCI_OFF_TIMEOUT); ++ if (err < 0) + pr_err("%s: cqhci: CQE stuck on\n", mmc_hostname(mmc)); + else + pr_debug("%s: cqhci: CQE off\n", mmc_hostname(mmc)); diff --git a/queue-4.19/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch b/queue-4.19/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch new file mode 100644 index 00000000000..e5db0ff5924 --- /dev/null +++ b/queue-4.19/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch @@ -0,0 +1,67 @@ +From ddca1092c4324c89cf692b5efe655aa251864b51 Mon Sep 17 00:00:00 2001 +From: Martin Blumenstingl +Date: Thu, 16 Apr 2020 20:35:13 +0200 +Subject: mmc: meson-mx-sdio: remove the broken ->card_busy() op + +From: Martin Blumenstingl + +commit ddca1092c4324c89cf692b5efe655aa251864b51 upstream. + +The recent commit 0d84c3e6a5b2 ("mmc: core: Convert to +mmc_poll_for_busy() for erase/trim/discard") makes use of the +->card_busy() op for SD cards. This uncovered that the ->card_busy() op +in the Meson SDIO driver was never working right: +while polling the busy status with ->card_busy() +meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC +register values 0x1f001f10 or 0x1f003f10. This translates to "three out +of four DAT lines are HIGH" and "all four DAT lines are HIGH", which +is interpreted as "the card is busy". + +It turns out that no situation can be observed where all four DAT lines +are LOW, meaning the card is not busy anymore. Upon further research the +3.10 vendor driver for this controller does not implement the +->card_busy() op. + +Remove the ->card_busy() op from the meson-mx-sdio driver since it is +not working. At the time of writing this patch it is not clear what's +needed to make the ->card_busy() implementation work with this specific +controller hardware. For all use-cases which have previously worked the +MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have +a ->card_busy() op anymore. + +Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") +Signed-off-by: Martin Blumenstingl +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/meson-mx-sdio.c | 9 --------- + 1 file changed, 9 deletions(-) + +--- a/drivers/mmc/host/meson-mx-sdio.c ++++ b/drivers/mmc/host/meson-mx-sdio.c +@@ -360,14 +360,6 @@ static void meson_mx_mmc_request(struct + meson_mx_mmc_start_cmd(mmc, mrq->cmd); + } + +-static int meson_mx_mmc_card_busy(struct mmc_host *mmc) +-{ +- struct meson_mx_mmc_host *host = mmc_priv(mmc); +- u32 irqc = readl(host->base + MESON_MX_SDIO_IRQC); +- +- return !!(irqc & MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK); +-} +- + static void meson_mx_mmc_read_response(struct mmc_host *mmc, + struct mmc_command *cmd) + { +@@ -509,7 +501,6 @@ static void meson_mx_mmc_timeout(struct + static struct mmc_host_ops meson_mx_mmc_ops = { + .request = meson_mx_mmc_request, + .set_ios = meson_mx_mmc_set_ios, +- .card_busy = meson_mx_mmc_card_busy, + .get_cd = mmc_gpio_get_cd, + .get_ro = mmc_gpio_get_ro, + }; diff --git a/queue-4.19/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch b/queue-4.19/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch new file mode 100644 index 00000000000..dfc7831905a --- /dev/null +++ b/queue-4.19/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch @@ -0,0 +1,38 @@ +From e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb Mon Sep 17 00:00:00 2001 +From: Martin Blumenstingl +Date: Thu, 16 Apr 2020 20:35:12 +0200 +Subject: mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY + +From: Martin Blumenstingl + +commit e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb upstream. + +The Meson SDIO controller uses the DAT0 lane for hardware busy +detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes +the following error observed with Linux 5.7 (pre-rc-1): + mmc1: Card stuck being busy! __mmc_poll_for_busy + blk_update_request: I/O error, dev mmcblk1, sector 17111080 op + 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 + +Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") +Signed-off-by: Martin Blumenstingl +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200416183513.993763-2-martin.blumenstingl@googlemail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/meson-mx-sdio.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/host/meson-mx-sdio.c ++++ b/drivers/mmc/host/meson-mx-sdio.c +@@ -573,7 +573,7 @@ static int meson_mx_mmc_add_host(struct + mmc->f_max = clk_round_rate(host->cfg_div_clk, + clk_get_rate(host->parent_clk)); + +- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23; ++ mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 | MMC_CAP_WAIT_WHILE_BUSY; + mmc->ops = &meson_mx_mmc_ops; + + ret = mmc_of_parse(mmc); diff --git a/queue-4.19/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch b/queue-4.19/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch new file mode 100644 index 00000000000..45486cfb7f9 --- /dev/null +++ b/queue-4.19/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch @@ -0,0 +1,42 @@ +From 9d8cb58691f85cef687512262acb2c7109ee4868 Mon Sep 17 00:00:00 2001 +From: Veerabhadrarao Badiganti +Date: Mon, 20 Apr 2020 11:50:23 +0530 +Subject: mmc: sdhci-msm: Enable host capabilities pertains to R1b response + +From: Veerabhadrarao Badiganti + +commit 9d8cb58691f85cef687512262acb2c7109ee4868 upstream. + +MSM sd host controller is capable of HW busy detection of device busy +signaling over DAT0 line. And it requires the R1B response for commands +that have this response associated with them. + +So set the below two host capabilities for qcom SDHC. + - MMC_CAP_WAIT_WHILE_BUSY + - MMC_CAP_NEED_RSP_BUSY + +Recent development of the mmc core in regards to this, revealed this as +being a potential bug, hence the stable tag. + +Cc: # v4.19+ +Signed-off-by: Veerabhadrarao Badiganti +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-msm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/mmc/host/sdhci-msm.c ++++ b/drivers/mmc/host/sdhci-msm.c +@@ -1909,6 +1909,8 @@ static int sdhci_msm_probe(struct platfo + goto clk_disable; + } + ++ msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY; ++ + pm_runtime_get_noresume(&pdev->dev); + pm_runtime_set_active(&pdev->dev); + pm_runtime_enable(&pdev->dev); diff --git a/queue-4.19/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch b/queue-4.19/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch new file mode 100644 index 00000000000..727da40f886 --- /dev/null +++ b/queue-4.19/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch @@ -0,0 +1,43 @@ +From 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 22 Apr 2020 14:16:29 +0300 +Subject: mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers + +From: Adrian Hunter + +commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream. + +BIOS writers have begun the practice of setting 40 ohm eMMC driver strength +even though the eMMC may not support it, on the assumption that the kernel +will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH +[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid. + +This is done to avoid changing the value for different boards. + +Putting aside the merits of this approach, it is clear the eMMC's mask +of supported driver strengths is more reliable than the value provided +by BIOS. Add validation accordingly. + +Signed-off-by: Adrian Hunter +Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-pci-core.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/mmc/host/sdhci-pci-core.c ++++ b/drivers/mmc/host/sdhci-pci-core.c +@@ -556,6 +556,9 @@ static int intel_select_drive_strength(s + struct sdhci_pci_slot *slot = sdhci_priv(host); + struct intel_host *intel_host = sdhci_pci_priv(slot); + ++ if (!(mmc_driver_type_mask(intel_host->drv_strength) & card_drv)) ++ return 0; ++ + return intel_host->drv_strength; + } + diff --git a/queue-4.19/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-4.19/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..3a675b35e24 --- /dev/null +++ b/queue-4.19/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch @@ -0,0 +1,58 @@ +From bb32e1987bc55ce1db400faf47d85891da3c9b9f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= +Date: Mon, 20 Apr 2020 10:04:44 +0200 +Subject: mmc: sdhci-xenon: fix annoying 1.8V regulator warning +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marek Behún + +commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream. + +For some reason the Host Control2 register of the Xenon SDHCI controller +sometimes reports the bit representing 1.8V signaling as 0 when read +after it was written as 1. Subsequent read reports 1. + +This causes the sdhci_start_signal_voltage_switch function to report + 1.8V regulator output did not become stable + +When CONFIG_PM is enabled, the host is suspended and resumend many +times, and in each resume the switch to 1.8V is called, and so the +kernel log reports this message annoyingly often. + +Do an empty read of the Host Control2 register in Xenon's +.voltage_switch method to circumvent this. + +This patch fixes this particular problem on Turris MOX. + +Signed-off-by: Marek Behún +Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...") +Cc: stable@vger.kernel.org # v4.16+ +Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-xenon.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/mmc/host/sdhci-xenon.c ++++ b/drivers/mmc/host/sdhci-xenon.c +@@ -238,6 +238,16 @@ static void xenon_voltage_switch(struct + { + /* Wait for 5ms after set 1.8V signal enable bit */ + usleep_range(5000, 5500); ++ ++ /* ++ * For some reason the controller's Host Control2 register reports ++ * the bit representing 1.8V signaling as 0 when read after it was ++ * written as 1. Subsequent read reports 1. ++ * ++ * Since this may cause some issues, do an empty read of the Host ++ * Control2 register here to circumvent this. ++ */ ++ sdhci_readw(host, SDHCI_HOST_CONTROL2); + } + + static const struct sdhci_ops sdhci_xenon_ops = { diff --git a/queue-4.19/series b/queue-4.19/series index e69de29bb2d..63f604fb124 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -0,0 +1,13 @@ +drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch +drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch +drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch +drm-qxl-qxl_release-use-after-free.patch +btrfs-fix-block-group-leak-when-removing-fails.patch +btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch +btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch +mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch +mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch +mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch +mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch +mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch +mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch -- 2.47.3