From b1380d065127bb96e87dd135d64d19e94446ae90 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 4 May 2020 11:12:34 +0200 Subject: [PATCH] 4.14-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 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-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 ++++++++++++++++++ ...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 +++++++++++++++ ...r-strength-for-byt-based-controllers.patch | 43 ++++++ ...-fix-annoying-1.8v-regulator-warning.patch | 58 ++++++++ queue-4.14/series | 8 + 9 files changed, 573 insertions(+) create mode 100644 queue-4.14/btrfs-fix-block-group-leak-when-removing-fails.patch create mode 100644 queue-4.14/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch create mode 100644 queue-4.14/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch create mode 100644 queue-4.14/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch create mode 100644 queue-4.14/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch create mode 100644 queue-4.14/drm-qxl-qxl_release-use-after-free.patch create mode 100644 queue-4.14/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch create mode 100644 queue-4.14/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch diff --git a/queue-4.14/btrfs-fix-block-group-leak-when-removing-fails.patch b/queue-4.14/btrfs-fix-block-group-leak-when-removing-fails.patch new file mode 100644 index 00000000000..d02836f747c --- /dev/null +++ b/queue-4.14/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 +@@ -10554,7 +10554,7 @@ int btrfs_remove_block_group(struct btrf + path = btrfs_alloc_path(); + if (!path) { + ret = -ENOMEM; +- goto out; ++ goto out_put_group; + } + + /* +@@ -10591,7 +10591,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 */ +@@ -10614,13 +10614,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); + } + +@@ -10778,9 +10778,9 @@ int btrfs_remove_block_group(struct btrf + + ret = remove_block_group_free_space(trans, fs_info, 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); +@@ -11037,6 +11037,10 @@ int btrfs_init_space_info(struct btrfs_f + flags = BTRFS_BLOCK_GROUP_DATA; + ret = create_space_info(fs_info, flags, &space_info); + } ++ ++out_put_group: ++ /* Once for the lookup reference */ ++ btrfs_put_block_group(block_group); + out: + return ret; + } diff --git a/queue-4.14/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch b/queue-4.14/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch new file mode 100644 index 00000000000..356d514cf46 --- /dev/null +++ b/queue-4.14/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 +@@ -4155,6 +4155,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; +@@ -4169,9 +4172,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) { +@@ -4209,7 +4246,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.14/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch b/queue-4.14/drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch new file mode 100644 index 00000000000..42d90b424ee --- /dev/null +++ b/queue-4.14/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 +@@ -4502,7 +4502,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.14/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch b/queue-4.14/drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch new file mode 100644 index 00000000000..9a17be8e558 --- /dev/null +++ b/queue-4.14/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.14/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch b/queue-4.14/drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch new file mode 100644 index 00000000000..89eb7547f31 --- /dev/null +++ b/queue-4.14/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 +@@ -504,9 +504,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.14/drm-qxl-qxl_release-use-after-free.patch b/queue-4.14/drm-qxl-qxl_release-use-after-free.patch new file mode 100644 index 00000000000..b0e1e629e33 --- /dev/null +++ b/queue-4.14/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 +@@ -533,8 +533,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); +@@ -576,9 +576,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 +@@ -533,8 +533,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; + +@@ -701,8 +701,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); +@@ -747,8 +747,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.14/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch b/queue-4.14/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch new file mode 100644 index 00000000000..3c878c85919 --- /dev/null +++ b/queue-4.14/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 +@@ -490,6 +490,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.14/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-4.14/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..3a675b35e24 --- /dev/null +++ b/queue-4.14/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.14/series b/queue-4.14/series index 6a92190e3f3..44bbd767ec7 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -1 +1,9 @@ ext4-fix-special-inode-number-checks-in-__ext4_iget.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 +btrfs-fix-block-group-leak-when-removing-fails.patch +btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch +mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch +mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch -- 2.47.3