From 0c7a370395612afb57343ae3f78640eb952b1cf7 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 29 Aug 2021 09:06:40 +0200 Subject: [PATCH] 5.13-stable patches added patches: can-usb-esd_usb2-esd_usb2_rx_event-fix-the-interchange-of-the-can-rx-and-tx-error-counters.patch ceph-correctly-handle-releasing-an-embedded-cap-flush.patch drm-amdgpu-cancel-delayed-work-when-gfxoff-is-disabled.patch drm-amdgpu-fix-build-with-missing-pm_suspend_target_state-module-export.patch drm-amdgpu-use-the-preferred-pin-domain-after-the-check.patch drm-i915-dp-drop-redundant-debug-print.patch drm-i915-fix-syncmap-memory-leak.patch dt-bindings-sifive-l2-cache-fix-select-matching.patch mm-memory_hotplug-fix-potential-permanent-lru-cache-disable.patch net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-buf-xdp.patch net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-xsk_pool.patch powerpc-re-enable-arch_enable_split_pmd_ptlock.patch revert-btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch revert-usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch riscv-ensure-the-value-of-fp-registers-in-the-core-dump-file-is-up-to-date.patch scsi-core-fix-hang-of-freezing-queue-between-blocking-and-running-device.patch usb-dwc3-gadget-fix-dwc3_calc_trbs_left.patch usb-dwc3-gadget-stop-ep0-transfers-during-pullup-disable.patch usb-renesas-xhci-prefer-firmware-loading-on-unknown-rom-state.patch usb-serial-option-add-new-vid-pid-to-support-fibocom-fg150.patch usb-typec-tcpm-raise-vdm_sm_running-flag-only-when-vdm-sm-is-running.patch --- ...-of-the-can-rx-and-tx-error-counters.patch | 40 +++ ...ndle-releasing-an-embedded-cap-flush.patch | 157 +++++++++ ...delayed-work-when-gfxoff-is-disabled.patch | 122 +++++++ ...m_suspend_target_state-module-export.patch | 54 ++++ ...preferred-pin-domain-after-the-check.patch | 53 +++ ...m-i915-dp-drop-redundant-debug-print.patch | 68 ++++ .../drm-i915-fix-syncmap-memory-leak.patch | 63 ++++ ...-sifive-l2-cache-fix-select-matching.patch | 41 +++ ...otential-permanent-lru-cache-disable.patch | 40 +++ ...-null-pointer-dereference-of-buf-xdp.patch | 61 ++++ ...null-pointer-dereference-of-xsk_pool.patch | 91 ++++++ ...-enable-arch_enable_split_pmd_ptlock.patch | 42 +++ ...mpress-if-we-don-t-have-enough-pages.patch | 61 ++++ ...haracter-loss-at-high-transfer-rates.patch | 44 +++ ...-in-the-core-dump-file-is-up-to-date.patch | 48 +++ ...-between-blocking-and-running-device.patch | 97 ++++++ queue-5.13/series | 21 ++ ...-dwc3-gadget-fix-dwc3_calc_trbs_left.patch | 60 ++++ ...-ep0-transfers-during-pullup-disable.patch | 59 ++++ ...irmware-loading-on-unknown-rom-state.patch | 123 +++++++ ...new-vid-pid-to-support-fibocom-fg150.patch | 278 ++++++++++++++++ ...ing-flag-only-when-vdm-sm-is-running.patch | 302 ++++++++++++++++++ 22 files changed, 1925 insertions(+) create mode 100644 queue-5.13/can-usb-esd_usb2-esd_usb2_rx_event-fix-the-interchange-of-the-can-rx-and-tx-error-counters.patch create mode 100644 queue-5.13/ceph-correctly-handle-releasing-an-embedded-cap-flush.patch create mode 100644 queue-5.13/drm-amdgpu-cancel-delayed-work-when-gfxoff-is-disabled.patch create mode 100644 queue-5.13/drm-amdgpu-fix-build-with-missing-pm_suspend_target_state-module-export.patch create mode 100644 queue-5.13/drm-amdgpu-use-the-preferred-pin-domain-after-the-check.patch create mode 100644 queue-5.13/drm-i915-dp-drop-redundant-debug-print.patch create mode 100644 queue-5.13/drm-i915-fix-syncmap-memory-leak.patch create mode 100644 queue-5.13/dt-bindings-sifive-l2-cache-fix-select-matching.patch create mode 100644 queue-5.13/mm-memory_hotplug-fix-potential-permanent-lru-cache-disable.patch create mode 100644 queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-buf-xdp.patch create mode 100644 queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-xsk_pool.patch create mode 100644 queue-5.13/powerpc-re-enable-arch_enable_split_pmd_ptlock.patch create mode 100644 queue-5.13/revert-btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch create mode 100644 queue-5.13/revert-usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch create mode 100644 queue-5.13/riscv-ensure-the-value-of-fp-registers-in-the-core-dump-file-is-up-to-date.patch create mode 100644 queue-5.13/scsi-core-fix-hang-of-freezing-queue-between-blocking-and-running-device.patch create mode 100644 queue-5.13/usb-dwc3-gadget-fix-dwc3_calc_trbs_left.patch create mode 100644 queue-5.13/usb-dwc3-gadget-stop-ep0-transfers-during-pullup-disable.patch create mode 100644 queue-5.13/usb-renesas-xhci-prefer-firmware-loading-on-unknown-rom-state.patch create mode 100644 queue-5.13/usb-serial-option-add-new-vid-pid-to-support-fibocom-fg150.patch create mode 100644 queue-5.13/usb-typec-tcpm-raise-vdm_sm_running-flag-only-when-vdm-sm-is-running.patch diff --git a/queue-5.13/can-usb-esd_usb2-esd_usb2_rx_event-fix-the-interchange-of-the-can-rx-and-tx-error-counters.patch b/queue-5.13/can-usb-esd_usb2-esd_usb2_rx_event-fix-the-interchange-of-the-can-rx-and-tx-error-counters.patch new file mode 100644 index 00000000000..c0dddc1d19f --- /dev/null +++ b/queue-5.13/can-usb-esd_usb2-esd_usb2_rx_event-fix-the-interchange-of-the-can-rx-and-tx-error-counters.patch @@ -0,0 +1,40 @@ +From 044012b52029204900af9e4230263418427f4ba4 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Stefan=20M=C3=A4tje?= +Date: Wed, 25 Aug 2021 23:52:27 +0200 +Subject: can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Stefan Mätje + +commit 044012b52029204900af9e4230263418427f4ba4 upstream. + +This patch fixes the interchanged fetch of the CAN RX and TX error +counters from the ESD_EV_CAN_ERROR_EXT message. The RX error counter +is really in struct rx_msg::data[2] and the TX error counter is in +struct rx_msg::data[3]. + +Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") +Link: https://lore.kernel.org/r/20210825215227.4947-2-stefan.maetje@esd.eu +Cc: stable@vger.kernel.org +Signed-off-by: Stefan Mätje +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/usb/esd_usb2.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/can/usb/esd_usb2.c ++++ b/drivers/net/can/usb/esd_usb2.c +@@ -224,8 +224,8 @@ static void esd_usb2_rx_event(struct esd + if (id == ESD_EV_CAN_ERROR_EXT) { + u8 state = msg->msg.rx.data[0]; + u8 ecc = msg->msg.rx.data[1]; +- u8 txerr = msg->msg.rx.data[2]; +- u8 rxerr = msg->msg.rx.data[3]; ++ u8 rxerr = msg->msg.rx.data[2]; ++ u8 txerr = msg->msg.rx.data[3]; + + skb = alloc_can_err_skb(priv->netdev, &cf); + if (skb == NULL) { diff --git a/queue-5.13/ceph-correctly-handle-releasing-an-embedded-cap-flush.patch b/queue-5.13/ceph-correctly-handle-releasing-an-embedded-cap-flush.patch new file mode 100644 index 00000000000..ac488d944c0 --- /dev/null +++ b/queue-5.13/ceph-correctly-handle-releasing-an-embedded-cap-flush.patch @@ -0,0 +1,157 @@ +From b2f9fa1f3bd8846f50b355fc2168236975c4d264 Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Wed, 18 Aug 2021 21:38:42 +0800 +Subject: ceph: correctly handle releasing an embedded cap flush + +From: Xiubo Li + +commit b2f9fa1f3bd8846f50b355fc2168236975c4d264 upstream. + +The ceph_cap_flush structures are usually dynamically allocated, but +the ceph_cap_snap has an embedded one. + +When force umounting, the client will try to remove all the session +caps. During this, it will free them, but that should not be done +with the ones embedded in a capsnap. + +Fix this by adding a new boolean that indicates that the cap flush is +embedded in a capsnap, and skip freeing it if that's set. + +At the same time, switch to using list_del_init() when detaching the +i_list and g_list heads. It's possible for a forced umount to remove +these objects but then handle_cap_flushsnap_ack() races in and does the +list_del_init() again, corrupting memory. + +Cc: stable@vger.kernel.org +URL: https://tracker.ceph.com/issues/52283 +Signed-off-by: Xiubo Li +Reviewed-by: Jeff Layton +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/caps.c | 21 +++++++++++++-------- + fs/ceph/mds_client.c | 7 ++++--- + fs/ceph/snap.c | 3 +++ + fs/ceph/super.h | 3 ++- + 4 files changed, 22 insertions(+), 12 deletions(-) + +--- a/fs/ceph/caps.c ++++ b/fs/ceph/caps.c +@@ -1753,7 +1753,11 @@ int __ceph_mark_dirty_caps(struct ceph_i + + struct ceph_cap_flush *ceph_alloc_cap_flush(void) + { +- return kmem_cache_alloc(ceph_cap_flush_cachep, GFP_KERNEL); ++ struct ceph_cap_flush *cf; ++ ++ cf = kmem_cache_alloc(ceph_cap_flush_cachep, GFP_KERNEL); ++ cf->is_capsnap = false; ++ return cf; + } + + void ceph_free_cap_flush(struct ceph_cap_flush *cf) +@@ -1788,7 +1792,7 @@ static bool __detach_cap_flush_from_mdsc + prev->wake = true; + wake = false; + } +- list_del(&cf->g_list); ++ list_del_init(&cf->g_list); + return wake; + } + +@@ -1803,7 +1807,7 @@ static bool __detach_cap_flush_from_ci(s + prev->wake = true; + wake = false; + } +- list_del(&cf->i_list); ++ list_del_init(&cf->i_list); + return wake; + } + +@@ -2423,7 +2427,7 @@ static void __kick_flushing_caps(struct + ci->i_ceph_flags &= ~CEPH_I_KICK_FLUSH; + + list_for_each_entry_reverse(cf, &ci->i_cap_flush_list, i_list) { +- if (!cf->caps) { ++ if (cf->is_capsnap) { + last_snap_flush = cf->tid; + break; + } +@@ -2442,7 +2446,7 @@ static void __kick_flushing_caps(struct + + first_tid = cf->tid + 1; + +- if (cf->caps) { ++ if (!cf->is_capsnap) { + struct cap_msg_args arg; + + dout("kick_flushing_caps %p cap %p tid %llu %s\n", +@@ -3589,7 +3593,7 @@ static void handle_cap_flush_ack(struct + cleaned = cf->caps; + + /* Is this a capsnap? */ +- if (cf->caps == 0) ++ if (cf->is_capsnap) + continue; + + if (cf->tid <= flush_tid) { +@@ -3662,8 +3666,9 @@ out: + while (!list_empty(&to_remove)) { + cf = list_first_entry(&to_remove, + struct ceph_cap_flush, i_list); +- list_del(&cf->i_list); +- ceph_free_cap_flush(cf); ++ list_del_init(&cf->i_list); ++ if (!cf->is_capsnap) ++ ceph_free_cap_flush(cf); + } + + if (wake_ci) +--- a/fs/ceph/mds_client.c ++++ b/fs/ceph/mds_client.c +@@ -1621,7 +1621,7 @@ static int remove_session_caps_cb(struct + spin_lock(&mdsc->cap_dirty_lock); + + list_for_each_entry(cf, &to_remove, i_list) +- list_del(&cf->g_list); ++ list_del_init(&cf->g_list); + + if (!list_empty(&ci->i_dirty_item)) { + pr_warn_ratelimited( +@@ -1673,8 +1673,9 @@ static int remove_session_caps_cb(struct + struct ceph_cap_flush *cf; + cf = list_first_entry(&to_remove, + struct ceph_cap_flush, i_list); +- list_del(&cf->i_list); +- ceph_free_cap_flush(cf); ++ list_del_init(&cf->i_list); ++ if (!cf->is_capsnap) ++ ceph_free_cap_flush(cf); + } + + wake_up_all(&ci->i_cap_wq); +--- a/fs/ceph/snap.c ++++ b/fs/ceph/snap.c +@@ -487,6 +487,9 @@ void ceph_queue_cap_snap(struct ceph_ino + pr_err("ENOMEM allocating ceph_cap_snap on %p\n", inode); + return; + } ++ capsnap->cap_flush.is_capsnap = true; ++ INIT_LIST_HEAD(&capsnap->cap_flush.i_list); ++ INIT_LIST_HEAD(&capsnap->cap_flush.g_list); + + spin_lock(&ci->i_ceph_lock); + used = __ceph_caps_used(ci); +--- a/fs/ceph/super.h ++++ b/fs/ceph/super.h +@@ -182,8 +182,9 @@ struct ceph_cap { + + struct ceph_cap_flush { + u64 tid; +- int caps; /* 0 means capsnap */ ++ int caps; + bool wake; /* wake up flush waiters when finish ? */ ++ bool is_capsnap; /* true means capsnap */ + struct list_head g_list; // global + struct list_head i_list; // per inode + }; diff --git a/queue-5.13/drm-amdgpu-cancel-delayed-work-when-gfxoff-is-disabled.patch b/queue-5.13/drm-amdgpu-cancel-delayed-work-when-gfxoff-is-disabled.patch new file mode 100644 index 00000000000..e0a1854cdf4 --- /dev/null +++ b/queue-5.13/drm-amdgpu-cancel-delayed-work-when-gfxoff-is-disabled.patch @@ -0,0 +1,122 @@ +From 32bc8f8373d2d6a681c96e4b25dca60d4d1c6016 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michel=20D=C3=A4nzer?= +Date: Tue, 17 Aug 2021 10:23:25 +0200 +Subject: drm/amdgpu: Cancel delayed work when GFXOFF is disabled +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michel Dänzer + +commit 32bc8f8373d2d6a681c96e4b25dca60d4d1c6016 upstream. + +schedule_delayed_work does not push back the work if it was already +scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms +after the first time GFXOFF was disabled and re-enabled, even if GFXOFF +was disabled and re-enabled again during those 100 ms. + +This resulted in frame drops / stutter with the upcoming mutter 41 +release on Navi 14, due to constantly enabling GFXOFF in the HW and +disabling it again (for getting the GPU clock counter). + +To fix this, call cancel_delayed_work_sync when the disable count +transitions from 0 to 1, and only schedule the delayed work on the +reverse transition, not if the disable count was already 0. This makes +sure the delayed work doesn't run at unexpected times, and allows it to +be lock-free. + +v2: +* Use cancel_delayed_work_sync & mutex_trylock instead of + mod_delayed_work. +v3: +* Make amdgpu_device_delay_enable_gfx_off lock-free (Christian König) +v4: +* Fix race condition between amdgpu_gfx_off_ctrl incrementing + adev->gfx.gfx_off_req_count and amdgpu_device_delay_enable_gfx_off + checking for it to be 0 (Evan Quan) + +Cc: stable@vger.kernel.org +Reviewed-by: Evan Quan +Reviewed-by: Lijo Lazar # v3 +Acked-by: Christian König # v3 +Signed-off-by: Michel Dänzer +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +++----- + drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 38 +++++++++++++++++++---------- + 2 files changed, 31 insertions(+), 18 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +@@ -2690,12 +2690,11 @@ static void amdgpu_device_delay_enable_g + struct amdgpu_device *adev = + container_of(work, struct amdgpu_device, gfx.gfx_off_delay_work.work); + +- mutex_lock(&adev->gfx.gfx_off_mutex); +- if (!adev->gfx.gfx_off_state && !adev->gfx.gfx_off_req_count) { +- if (!amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, true)) +- adev->gfx.gfx_off_state = true; +- } +- mutex_unlock(&adev->gfx.gfx_off_mutex); ++ WARN_ON_ONCE(adev->gfx.gfx_off_state); ++ WARN_ON_ONCE(adev->gfx.gfx_off_req_count); ++ ++ if (!amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, true)) ++ adev->gfx.gfx_off_state = true; + } + + /** +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c +@@ -563,24 +563,38 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_d + + mutex_lock(&adev->gfx.gfx_off_mutex); + +- if (!enable) +- adev->gfx.gfx_off_req_count++; +- else if (adev->gfx.gfx_off_req_count > 0) ++ if (enable) { ++ /* If the count is already 0, it means there's an imbalance bug somewhere. ++ * Note that the bug may be in a different caller than the one which triggers the ++ * WARN_ON_ONCE. ++ */ ++ if (WARN_ON_ONCE(adev->gfx.gfx_off_req_count == 0)) ++ goto unlock; ++ + adev->gfx.gfx_off_req_count--; + +- if (enable && !adev->gfx.gfx_off_state && !adev->gfx.gfx_off_req_count) { +- schedule_delayed_work(&adev->gfx.gfx_off_delay_work, GFX_OFF_DELAY_ENABLE); +- } else if (!enable && adev->gfx.gfx_off_state) { +- if (!amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, false)) { +- adev->gfx.gfx_off_state = false; +- +- if (adev->gfx.funcs->init_spm_golden) { +- dev_dbg(adev->dev, "GFXOFF is disabled, re-init SPM golden settings\n"); +- amdgpu_gfx_init_spm_golden(adev); ++ if (adev->gfx.gfx_off_req_count == 0 && !adev->gfx.gfx_off_state) ++ schedule_delayed_work(&adev->gfx.gfx_off_delay_work, GFX_OFF_DELAY_ENABLE); ++ } else { ++ if (adev->gfx.gfx_off_req_count == 0) { ++ cancel_delayed_work_sync(&adev->gfx.gfx_off_delay_work); ++ ++ if (adev->gfx.gfx_off_state && ++ !amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_GFX, false)) { ++ adev->gfx.gfx_off_state = false; ++ ++ if (adev->gfx.funcs->init_spm_golden) { ++ dev_dbg(adev->dev, ++ "GFXOFF is disabled, re-init SPM golden settings\n"); ++ amdgpu_gfx_init_spm_golden(adev); ++ } + } + } ++ ++ adev->gfx.gfx_off_req_count++; + } + ++unlock: + mutex_unlock(&adev->gfx.gfx_off_mutex); + } + diff --git a/queue-5.13/drm-amdgpu-fix-build-with-missing-pm_suspend_target_state-module-export.patch b/queue-5.13/drm-amdgpu-fix-build-with-missing-pm_suspend_target_state-module-export.patch new file mode 100644 index 00000000000..0bf207192c8 --- /dev/null +++ b/queue-5.13/drm-amdgpu-fix-build-with-missing-pm_suspend_target_state-module-export.patch @@ -0,0 +1,54 @@ +From c41a4e877a185241d8e83501453326fb98f67354 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Tue, 24 Aug 2021 11:42:47 +0200 +Subject: drm/amdgpu: Fix build with missing pm_suspend_target_state module export + +From: Borislav Petkov + +commit c41a4e877a185241d8e83501453326fb98f67354 upstream. + +Building a randconfig here triggered: + + ERROR: modpost: "pm_suspend_target_state" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! + +because the module export of that symbol happens in +kernel/power/suspend.c which is enabled with CONFIG_SUSPEND. + +The ifdef guards in amdgpu_acpi_is_s0ix_supported(), however, test for +CONFIG_PM_SLEEP which is defined like this: + + config PM_SLEEP + def_bool y + depends on SUSPEND || HIBERNATE_CALLBACKS + +and that randconfig has: + + # CONFIG_SUSPEND is not set + CONFIG_HIBERNATE_CALLBACKS=y + +leading to the module export missing. + +Change the ifdeffery to depend directly on CONFIG_SUSPEND. + +Fixes: 5706cb3c910c ("drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled") +Reviewed-by: Lijo Lazar +Signed-off-by: Borislav Petkov +Link: https://lkml.kernel.org/r/YSP6Lv53QV0cOAsd@zn.tnic +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +@@ -904,7 +904,7 @@ void amdgpu_acpi_fini(struct amdgpu_devi + */ + bool amdgpu_acpi_is_s0ix_supported(struct amdgpu_device *adev) + { +-#if IS_ENABLED(CONFIG_AMD_PMC) && IS_ENABLED(CONFIG_PM_SLEEP) ++#if IS_ENABLED(CONFIG_AMD_PMC) && IS_ENABLED(CONFIG_SUSPEND) + if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) { + if (adev->flags & AMD_IS_APU) + return pm_suspend_target_state == PM_SUSPEND_TO_IDLE; diff --git a/queue-5.13/drm-amdgpu-use-the-preferred-pin-domain-after-the-check.patch b/queue-5.13/drm-amdgpu-use-the-preferred-pin-domain-after-the-check.patch new file mode 100644 index 00000000000..92c479fc60e --- /dev/null +++ b/queue-5.13/drm-amdgpu-use-the-preferred-pin-domain-after-the-check.patch @@ -0,0 +1,53 @@ +From 2a7b9a8437130fd328001f4edfac8eec98dfe298 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= +Date: Wed, 18 Aug 2021 14:05:28 +0200 +Subject: drm/amdgpu: use the preferred pin domain after the check +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian König + +commit 2a7b9a8437130fd328001f4edfac8eec98dfe298 upstream. + +For some reason we run into an use case where a BO is already pinned +into GTT, but should be pinned into VRAM|GTT again. + +Handle that case gracefully as well. + +Reviewed-by: Shashank Sharma +Reviewed-by: Alex Deucher +Signed-off-by: Christian König +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +@@ -937,11 +937,6 @@ int amdgpu_bo_pin_restricted(struct amdg + return -EINVAL; + } + +- /* This assumes only APU display buffers are pinned with (VRAM|GTT). +- * See function amdgpu_display_supported_domains() +- */ +- domain = amdgpu_bo_get_preferred_pin_domain(adev, domain); +- + if (bo->tbo.pin_count) { + uint32_t mem_type = bo->tbo.mem.mem_type; + uint32_t mem_flags = bo->tbo.mem.placement; +@@ -966,6 +961,11 @@ int amdgpu_bo_pin_restricted(struct amdg + return 0; + } + ++ /* This assumes only APU display buffers are pinned with (VRAM|GTT). ++ * See function amdgpu_display_supported_domains() ++ */ ++ domain = amdgpu_bo_get_preferred_pin_domain(adev, domain); ++ + if (bo->tbo.base.import_attach) + dma_buf_pin(bo->tbo.base.import_attach); + diff --git a/queue-5.13/drm-i915-dp-drop-redundant-debug-print.patch b/queue-5.13/drm-i915-dp-drop-redundant-debug-print.patch new file mode 100644 index 00000000000..595136d6ccb --- /dev/null +++ b/queue-5.13/drm-i915-dp-drop-redundant-debug-print.patch @@ -0,0 +1,68 @@ +From 71de496cc489b6bae2f51f89da7f28849bf2836e Mon Sep 17 00:00:00 2001 +From: Swati Sharma +Date: Thu, 12 Aug 2021 18:41:07 +0530 +Subject: drm/i915/dp: Drop redundant debug print +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Swati Sharma + +commit 71de496cc489b6bae2f51f89da7f28849bf2836e upstream. + +drm_dp_dpcd_read/write already has debug error message. +Drop redundant error messages which gives false +status even if correct value is read in drm_dp_dpcd_read(). + +v2: -Added fixes tag (Ankit) +v3: -Fixed build error (CI) + +Fixes: 9488a030ac91 ("drm/i915: Add support for enabling link status and recovery") +Cc: Ankit Nautiyal +Cc: Imre Deak +Cc: Jani Nikula +Cc: José Roberto de Souza +Cc: Manasi Navare +Cc: Sean Paul +Cc: Uma Shankar +Cc: Ville Syrjälä +Cc: # v5.12+ +Reviewed-by: Jani Nikula +Signed-off-by: Swati Sharma +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20210812131107.5531-1-swati2.sharma@intel.com +(cherry picked from commit b6dfa416172939edaa46a5a647457b94c6d94119) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_dp.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/i915/display/intel_dp.c ++++ b/drivers/gpu/drm/i915/display/intel_dp.c +@@ -3833,23 +3833,18 @@ static void intel_dp_check_device_servic + + static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp) + { +- struct drm_i915_private *i915 = dp_to_i915(intel_dp); + u8 val; + + if (intel_dp->dpcd[DP_DPCD_REV] < 0x11) + return; + + if (drm_dp_dpcd_readb(&intel_dp->aux, +- DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 || !val) { +- drm_dbg_kms(&i915->drm, "Error in reading link service irq vector\n"); ++ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 || !val) + return; +- } + + if (drm_dp_dpcd_writeb(&intel_dp->aux, +- DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) { +- drm_dbg_kms(&i915->drm, "Error in writing link service irq vector\n"); ++ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) + return; +- } + + if (val & HDMI_LINK_STATUS_CHANGED) + intel_dp_handle_hdmi_link_status_change(intel_dp); diff --git a/queue-5.13/drm-i915-fix-syncmap-memory-leak.patch b/queue-5.13/drm-i915-fix-syncmap-memory-leak.patch new file mode 100644 index 00000000000..3f65c55dc94 --- /dev/null +++ b/queue-5.13/drm-i915-fix-syncmap-memory-leak.patch @@ -0,0 +1,63 @@ +From a63bcf08f0efb5348105bb8e0e1e8c6671077753 Mon Sep 17 00:00:00 2001 +From: Matthew Brost +Date: Fri, 30 Jul 2021 12:53:42 -0700 +Subject: drm/i915: Fix syncmap memory leak + +From: Matthew Brost + +commit a63bcf08f0efb5348105bb8e0e1e8c6671077753 upstream. + +A small race exists between intel_gt_retire_requests_timeout and +intel_timeline_exit which could result in the syncmap not getting +free'd. Rather than work to hard to seal this race, simply cleanup the +syncmap on fini. + +unreferenced object 0xffff88813bc53b18 (size 96): + comm "gem_close_race", pid 5410, jiffies 4294917818 (age 1105.600s) + hex dump (first 32 bytes): + 01 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 ................ + 00 00 00 00 00 00 00 00 6b 6b 6b 6b 06 00 00 00 ........kkkk.... + backtrace: + [<00000000120b863a>] __sync_alloc_leaf+0x1e/0x40 [i915] + [<00000000042f6959>] __sync_set+0x1bb/0x240 [i915] + [<0000000090f0e90f>] i915_request_await_dma_fence+0x1c7/0x400 [i915] + [<0000000056a48219>] i915_request_await_object+0x222/0x360 [i915] + [<00000000aaac4ee3>] i915_gem_do_execbuffer+0x1bd0/0x2250 [i915] + [<000000003c9d830f>] i915_gem_execbuffer2_ioctl+0x405/0xce0 [i915] + [<00000000fd7a8e68>] drm_ioctl_kernel+0xb0/0xf0 [drm] + [<00000000e721ee87>] drm_ioctl+0x305/0x3c0 [drm] + [<000000008b0d8986>] __x64_sys_ioctl+0x71/0xb0 + [<0000000076c362a4>] do_syscall_64+0x33/0x80 + [<00000000eb7a4831>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Signed-off-by: Matthew Brost +Fixes: 531958f6f357 ("drm/i915/gt: Track timeline activeness in enter/exit") +Cc: +Reviewed-by: John Harrison +Signed-off-by: John Harrison +Link: https://patchwork.freedesktop.org/patch/msgid/20210730195342.110234-1-matthew.brost@intel.com +(cherry picked from commit faf890985e30d5e88cc3a7c50c1bcad32f89ab7c) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/gt/intel_timeline.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/gpu/drm/i915/gt/intel_timeline.c ++++ b/drivers/gpu/drm/i915/gt/intel_timeline.c +@@ -127,6 +127,15 @@ static void intel_timeline_fini(struct r + + i915_vma_put(timeline->hwsp_ggtt); + i915_active_fini(&timeline->active); ++ ++ /* ++ * A small race exists between intel_gt_retire_requests_timeout and ++ * intel_timeline_exit which could result in the syncmap not getting ++ * free'd. Rather than work to hard to seal this race, simply cleanup ++ * the syncmap on fini. ++ */ ++ i915_syncmap_free(&timeline->sync); ++ + kfree(timeline); + } + diff --git a/queue-5.13/dt-bindings-sifive-l2-cache-fix-select-matching.patch b/queue-5.13/dt-bindings-sifive-l2-cache-fix-select-matching.patch new file mode 100644 index 00000000000..3a3e852bb7e --- /dev/null +++ b/queue-5.13/dt-bindings-sifive-l2-cache-fix-select-matching.patch @@ -0,0 +1,41 @@ +From 1c8094e394bceb4f1880f9d539bdd255c130826e Mon Sep 17 00:00:00 2001 +From: Rob Herring +Date: Tue, 17 Aug 2021 12:47:55 -0500 +Subject: dt-bindings: sifive-l2-cache: Fix 'select' matching + +From: Rob Herring + +commit 1c8094e394bceb4f1880f9d539bdd255c130826e upstream. + +When the schema fixups are applied to 'select' the result is a single +entry is required for a match, but that will never match as there should +be 2 entries. Also, a 'select' schema should have the widest possible +match, so use 'contains' which matches the compatible string(s) in any +position and not just the first position. + +Fixes: 993dcfac64eb ("dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema") +Signed-off-by: Rob Herring +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml ++++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +@@ -24,10 +24,10 @@ allOf: + select: + properties: + compatible: +- items: +- - enum: +- - sifive,fu540-c000-ccache +- - sifive,fu740-c000-ccache ++ contains: ++ enum: ++ - sifive,fu540-c000-ccache ++ - sifive,fu740-c000-ccache + + required: + - compatible diff --git a/queue-5.13/mm-memory_hotplug-fix-potential-permanent-lru-cache-disable.patch b/queue-5.13/mm-memory_hotplug-fix-potential-permanent-lru-cache-disable.patch new file mode 100644 index 00000000000..1bc86e27dfb --- /dev/null +++ b/queue-5.13/mm-memory_hotplug-fix-potential-permanent-lru-cache-disable.patch @@ -0,0 +1,40 @@ +From 946746d1ad921e5f493b536533dda02ea22ca609 Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Wed, 25 Aug 2021 12:17:55 -0700 +Subject: mm/memory_hotplug: fix potential permanent lru cache disable + +From: Miaohe Lin + +commit 946746d1ad921e5f493b536533dda02ea22ca609 upstream. + +If offline_pages failed after lru_cache_disable(), it forgot to do +lru_cache_enable() in error path. So we would have lru cache disabled +permanently in this case. + +Link: https://lkml.kernel.org/r/20210821094246.10149-3-linmiaohe@huawei.com +Fixes: d479960e44f2 ("mm: disable LRU pagevec during the migration temporarily") +Signed-off-by: Miaohe Lin +Reviewed-by: David Hildenbrand +Reviewed-by: Oscar Salvador +Reviewed-by: Naoya Horiguchi +Cc: Chris Goldsworthy +Cc: Michal Hocko +Cc: Minchan Kim +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory_hotplug.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/memory_hotplug.c ++++ b/mm/memory_hotplug.c +@@ -1854,6 +1854,7 @@ failed_removal_isolated: + undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); + memory_notify(MEM_CANCEL_OFFLINE, &arg); + failed_removal_pcplists_disabled: ++ lru_cache_enable(); + zone_pcp_enable(zone); + failed_removal: + pr_debug("memory offlining [mem %#010llx-%#010llx] failed due to %s\n", diff --git a/queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-buf-xdp.patch b/queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-buf-xdp.patch new file mode 100644 index 00000000000..89ac7079d0c --- /dev/null +++ b/queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-buf-xdp.patch @@ -0,0 +1,61 @@ +From 2b9fff64f03219d78044d1ab40dde8e3d42e968a Mon Sep 17 00:00:00 2001 +From: Song Yoong Siang +Date: Wed, 25 Aug 2021 08:57:42 +0800 +Subject: net: stmmac: fix kernel panic due to NULL pointer dereference of buf->xdp + +From: Song Yoong Siang + +commit 2b9fff64f03219d78044d1ab40dde8e3d42e968a upstream. + +Ensure a valid XSK buffer before proceed to free the xdp buffer. + +The following kernel panic is observed without this patch: + +RIP: 0010:xp_free+0x5/0x40 +Call Trace: +stmmac_napi_poll_rxtx+0x332/0xb30 [stmmac] +? stmmac_tx_timer+0x3c/0xb0 [stmmac] +net_rx_action+0x13d/0x3d0 +__do_softirq+0xfc/0x2fb +? smpboot_register_percpu_thread+0xe0/0xe0 +run_ksoftirqd+0x32/0x70 +smpboot_thread_fn+0x1d8/0x2c0 +kthread+0x169/0x1a0 +? kthread_park+0x90/0x90 +ret_from_fork+0x1f/0x30 +---[ end trace 0000000000000002 ]--- + +Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") +Cc: # 5.13.x +Suggested-by: Ong Boon Leong +Signed-off-by: Song Yoong Siang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +@@ -4925,6 +4925,10 @@ read_again: + + prefetch(np); + ++ /* Ensure a valid XSK buffer before proceed */ ++ if (!buf->xdp) ++ break; ++ + if (priv->extend_desc) + stmmac_rx_extended_status(priv, &priv->dev->stats, + &priv->xstats, +@@ -4945,10 +4949,6 @@ read_again: + continue; + } + +- /* Ensure a valid XSK buffer before proceed */ +- if (!buf->xdp) +- break; +- + /* XSK pool expects RX frame 1:1 mapped to XSK buffer */ + if (likely(status & rx_not_ls)) { + xsk_buff_free(buf->xdp); diff --git a/queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-xsk_pool.patch b/queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-xsk_pool.patch new file mode 100644 index 00000000000..4a640901875 --- /dev/null +++ b/queue-5.13/net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-xsk_pool.patch @@ -0,0 +1,91 @@ +From a6451192da2691dcf39507bd758dde35d4606ee1 Mon Sep 17 00:00:00 2001 +From: Song Yoong Siang +Date: Wed, 25 Aug 2021 08:55:29 +0800 +Subject: net: stmmac: fix kernel panic due to NULL pointer dereference of xsk_pool + +From: Song Yoong Siang + +commit a6451192da2691dcf39507bd758dde35d4606ee1 upstream. + +After free xsk_pool, there is possibility that napi polling is still +running in the middle, thus causes a kernel crash due to kernel NULL +pointer dereference of rx_q->xsk_pool and tx_q->xsk_pool. + +Fix this by changing the XDP pool setup sequence to: + 1. disable napi before free xsk_pool + 2. enable napi after init xsk_pool + +The following kernel panic is observed without this patch: + +RIP: 0010:xsk_uses_need_wakeup+0x5/0x10 +Call Trace: +stmmac_napi_poll_rxtx+0x3a9/0xae0 [stmmac] +__napi_poll+0x27/0x130 +net_rx_action+0x233/0x280 +__do_softirq+0xe2/0x2b6 +run_ksoftirqd+0x1a/0x20 +smpboot_thread_fn+0xac/0x140 +? sort_range+0x20/0x20 +kthread+0x124/0x150 +? set_kthread_struct+0x40/0x40 +ret_from_fork+0x1f/0x30 +---[ end trace a77c8956b79ac107 ]--- + +Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") +Cc: # 5.13.x +Signed-off-by: Song Yoong Siang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c +@@ -34,18 +34,18 @@ static int stmmac_xdp_enable_pool(struct + need_update = netif_running(priv->dev) && stmmac_xdp_is_enabled(priv); + + if (need_update) { +- stmmac_disable_rx_queue(priv, queue); +- stmmac_disable_tx_queue(priv, queue); + napi_disable(&ch->rx_napi); + napi_disable(&ch->tx_napi); ++ stmmac_disable_rx_queue(priv, queue); ++ stmmac_disable_tx_queue(priv, queue); + } + + set_bit(queue, priv->af_xdp_zc_qps); + + if (need_update) { +- napi_enable(&ch->rxtx_napi); + stmmac_enable_rx_queue(priv, queue); + stmmac_enable_tx_queue(priv, queue); ++ napi_enable(&ch->rxtx_napi); + + err = stmmac_xsk_wakeup(priv->dev, queue, XDP_WAKEUP_RX); + if (err) +@@ -72,10 +72,10 @@ static int stmmac_xdp_disable_pool(struc + need_update = netif_running(priv->dev) && stmmac_xdp_is_enabled(priv); + + if (need_update) { ++ napi_disable(&ch->rxtx_napi); + stmmac_disable_rx_queue(priv, queue); + stmmac_disable_tx_queue(priv, queue); + synchronize_rcu(); +- napi_disable(&ch->rxtx_napi); + } + + xsk_pool_dma_unmap(pool, STMMAC_RX_DMA_ATTR); +@@ -83,10 +83,10 @@ static int stmmac_xdp_disable_pool(struc + clear_bit(queue, priv->af_xdp_zc_qps); + + if (need_update) { +- napi_enable(&ch->rx_napi); +- napi_enable(&ch->tx_napi); + stmmac_enable_rx_queue(priv, queue); + stmmac_enable_tx_queue(priv, queue); ++ napi_enable(&ch->rx_napi); ++ napi_enable(&ch->tx_napi); + } + + return 0; diff --git a/queue-5.13/powerpc-re-enable-arch_enable_split_pmd_ptlock.patch b/queue-5.13/powerpc-re-enable-arch_enable_split_pmd_ptlock.patch new file mode 100644 index 00000000000..1f1e82b1ddd --- /dev/null +++ b/queue-5.13/powerpc-re-enable-arch_enable_split_pmd_ptlock.patch @@ -0,0 +1,42 @@ +From 310d2e83cb9b7f1e7232319880e3fcb57592fa10 Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +Date: Thu, 19 Aug 2021 13:39:54 +0200 +Subject: powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK + +From: Lukas Bulwahn + +commit 310d2e83cb9b7f1e7232319880e3fcb57592fa10 upstream. + +Commit 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK") +broke PMD split page table lock for powerpc. + +It selects the non-existent config ARCH_ENABLE_PMD_SPLIT_PTLOCK in +arch/powerpc/platforms/Kconfig.cputype, but clearly intended to +select ARCH_ENABLE_SPLIT_PMD_PTLOCK (notice the word swapping!), as +that commit did for all other architectures. + +Fix it by selecting the correct symbol ARCH_ENABLE_SPLIT_PMD_PTLOCK. + +Fixes: 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK") +Cc: stable@vger.kernel.org # v5.13+ +Signed-off-by: Lukas Bulwahn +Reviewed-by: Daniel Axtens +[mpe: Reword change log to make it clear this is a bug fix] +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20210819113954.17515-3-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/platforms/Kconfig.cputype | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/platforms/Kconfig.cputype ++++ b/arch/powerpc/platforms/Kconfig.cputype +@@ -97,7 +97,7 @@ config PPC_BOOK3S_64 + select PPC_HAVE_PMU_SUPPORT + select HAVE_ARCH_TRANSPARENT_HUGEPAGE + select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION +- select ARCH_ENABLE_PMD_SPLIT_PTLOCK ++ select ARCH_ENABLE_SPLIT_PMD_PTLOCK + select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE + select ARCH_SUPPORTS_HUGETLBFS + select ARCH_SUPPORTS_NUMA_BALANCING diff --git a/queue-5.13/revert-btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch b/queue-5.13/revert-btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch new file mode 100644 index 00000000000..a4ae51d9f4d --- /dev/null +++ b/queue-5.13/revert-btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch @@ -0,0 +1,61 @@ +From 4e9655763b82a91e4c341835bb504a2b1590f984 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Wed, 25 Aug 2021 13:41:42 +0800 +Subject: Revert "btrfs: compression: don't try to compress if we don't have enough pages" + +From: Qu Wenruo + +commit 4e9655763b82a91e4c341835bb504a2b1590f984 upstream. + +This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763. + +[BUG] +It's no longer possible to create compressed inline extent after commit +f2165627319f ("btrfs: compression: don't try to compress if we don't +have enough pages"). + +[CAUSE] +For compression code, there are several possible reasons we have a range +that needs to be compressed while it's no more than one page. + +- Compressed inline write + The data is always smaller than one sector and the test lacks the + condition to properly recognize a non-inline extent. + +- Compressed subpage write + For the incoming subpage compressed write support, we require page + alignment of the delalloc range. + And for 64K page size, we can compress just one page into smaller + sectors. + +For those reasons, the requirement for the data to be more than one page +is not correct, and is already causing regression for compressed inline +data writeback. The idea of skipping one page to avoid wasting CPU time +could be revisited in the future. + +[FIX] +Fix it by reverting the offending commit. + +Reported-by: Zygo Blaxell +Link: https://lore.kernel.org/linux-btrfs/afa2742.c084f5d6.17b6b08dffc@tnonline.net +Fixes: f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages") +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/inode.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -603,7 +603,7 @@ again: + * inode has not been flagged as nocompress. This flag can + * change at any time if we discover bad compression ratios. + */ +- if (nr_pages > 1 && inode_need_compress(BTRFS_I(inode), start, end)) { ++ if (inode_need_compress(BTRFS_I(inode), start, end)) { + WARN_ON(pages); + pages = kcalloc(nr_pages, sizeof(struct page *), GFP_NOFS); + if (!pages) { diff --git a/queue-5.13/revert-usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch b/queue-5.13/revert-usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch new file mode 100644 index 00000000000..a20de062a58 --- /dev/null +++ b/queue-5.13/revert-usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch @@ -0,0 +1,44 @@ +From df7b16d1c00ecb3da3a30c999cdb39f273c99a2f Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Tue, 24 Aug 2021 14:19:26 +0200 +Subject: Revert "USB: serial: ch341: fix character loss at high transfer rates" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Johan Hovold + +commit df7b16d1c00ecb3da3a30c999cdb39f273c99a2f upstream. + +This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b. + +These devices do not appear to send a zero-length packet when the +transfer size is a multiple of the bulk-endpoint max-packet size. This +means that incoming data may not be processed by the driver until a +short packet is received or the receive buffer is full. + +Revert back to using endpoint-sized receive buffers to avoid stalled +reads. + +Reported-by: Paul Größel +Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131 +Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates") +Cc: stable@vger.kernel.org +Cc: Willy Tarreau +Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/ch341.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/usb/serial/ch341.c ++++ b/drivers/usb/serial/ch341.c +@@ -851,7 +851,6 @@ static struct usb_serial_driver ch341_de + .owner = THIS_MODULE, + .name = "ch341-uart", + }, +- .bulk_in_size = 512, + .id_table = id_table, + .num_ports = 1, + .open = ch341_open, diff --git a/queue-5.13/riscv-ensure-the-value-of-fp-registers-in-the-core-dump-file-is-up-to-date.patch b/queue-5.13/riscv-ensure-the-value-of-fp-registers-in-the-core-dump-file-is-up-to-date.patch new file mode 100644 index 00000000000..d110f0ae6a5 --- /dev/null +++ b/queue-5.13/riscv-ensure-the-value-of-fp-registers-in-the-core-dump-file-is-up-to-date.patch @@ -0,0 +1,48 @@ +From 379eb01c21795edb4ca8d342503bd2183a19ec3a Mon Sep 17 00:00:00 2001 +From: Vincent Chen +Date: Tue, 3 Aug 2021 17:27:51 +0800 +Subject: riscv: Ensure the value of FP registers in the core dump file is up to date + +From: Vincent Chen + +commit 379eb01c21795edb4ca8d342503bd2183a19ec3a upstream. + +The value of FP registers in the core dump file comes from the +thread.fstate. However, kernel saves the FP registers to the thread.fstate +only before scheduling out the process. If no process switch happens +during the exception handling process, kernel will not have a chance to +save the latest value of FP registers to thread.fstate. It will cause the +value of FP registers in the core dump file may be incorrect. To solve this +problem, this patch force lets kernel save the FP register into the +thread.fstate if the target task_struct equals the current. + +Signed-off-by: Vincent Chen +Reviewed-by: Jisheng Zhang +Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.") +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/ptrace.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/riscv/kernel/ptrace.c ++++ b/arch/riscv/kernel/ptrace.c +@@ -10,6 +10,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -56,6 +57,9 @@ static int riscv_fpr_get(struct task_str + { + struct __riscv_d_ext_state *fstate = &target->thread.fstate; + ++ if (target == current) ++ fstate_save(current, task_pt_regs(current)); ++ + membuf_write(&to, fstate, offsetof(struct __riscv_d_ext_state, fcsr)); + membuf_store(&to, fstate->fcsr); + return membuf_zero(&to, 4); // explicitly pad diff --git a/queue-5.13/scsi-core-fix-hang-of-freezing-queue-between-blocking-and-running-device.patch b/queue-5.13/scsi-core-fix-hang-of-freezing-queue-between-blocking-and-running-device.patch new file mode 100644 index 00000000000..b866e068170 --- /dev/null +++ b/queue-5.13/scsi-core-fix-hang-of-freezing-queue-between-blocking-and-running-device.patch @@ -0,0 +1,97 @@ +From 02c6dcd543f8f051973ee18bfbc4dc3bd595c558 Mon Sep 17 00:00:00 2001 +From: Li Jinlin +Date: Tue, 24 Aug 2021 10:59:21 +0800 +Subject: scsi: core: Fix hang of freezing queue between blocking and running device + +From: Li Jinlin + +commit 02c6dcd543f8f051973ee18bfbc4dc3bd595c558 upstream. + +We found a hang, the steps to reproduce are as follows: + + 1. blocking device via scsi_device_set_state() + + 2. dd if=/dev/sda of=/mnt/t.log bs=1M count=10 + + 3. echo none > /sys/block/sda/queue/scheduler + + 4. echo "running" >/sys/block/sda/device/state + +Step 3 and 4 should complete after step 4, but they hang. + + CPU#0 CPU#1 CPU#2 + --------------- ---------------- ---------------- + Step 1: blocking device + + Step 2: dd xxxx + ^^^^^^ get request + q_usage_counter++ + + Step 3: switching scheculer + elv_iosched_store + elevator_switch + blk_mq_freeze_queue + blk_freeze_queue + > blk_freeze_queue_start + ^^^^^^ mq_freeze_depth++ + + > blk_mq_run_hw_queues + ^^^^^^ can't run queue when dev blocked + + > blk_mq_freeze_queue_wait + ^^^^^^ Hang here!!! + wait q_usage_counter==0 + + Step 4: running device + store_state_field + scsi_rescan_device + scsi_attach_vpd + scsi_vpd_inquiry + __scsi_execute + blk_get_request + blk_mq_alloc_request + blk_queue_enter + ^^^^^^ Hang here!!! + wait mq_freeze_depth==0 + + blk_mq_run_hw_queues + ^^^^^^ dispatch IO, q_usage_counter will reduce to zero + + blk_mq_unfreeze_queue + ^^^^^ mq_freeze_depth-- + +To fix this, we need to run queue before rescanning device when the device +state changes to SDEV_RUNNING. + +Link: https://lore.kernel.org/r/20210824025921.3277629-1-lijinlin3@huawei.com +Fixes: f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device") +Reviewed-by: Bart Van Assche +Signed-off-by: Li Jinlin +Signed-off-by: Qiu Laibin +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/scsi_sysfs.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/scsi/scsi_sysfs.c ++++ b/drivers/scsi/scsi_sysfs.c +@@ -808,12 +808,15 @@ store_state_field(struct device *dev, st + ret = scsi_device_set_state(sdev, state); + /* + * If the device state changes to SDEV_RUNNING, we need to +- * rescan the device to revalidate it, and run the queue to +- * avoid I/O hang. ++ * run the queue to avoid I/O hang, and rescan the device ++ * to revalidate it. Running the queue first is necessary ++ * because another thread may be waiting inside ++ * blk_mq_freeze_queue_wait() and because that call may be ++ * waiting for pending I/O to finish. + */ + if (ret == 0 && state == SDEV_RUNNING) { +- scsi_rescan_device(dev); + blk_mq_run_hw_queues(sdev->request_queue, true); ++ scsi_rescan_device(dev); + } + mutex_unlock(&sdev->state_mutex); + diff --git a/queue-5.13/series b/queue-5.13/series index f63422d2783..b296c25193e 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -11,3 +11,24 @@ io_uring-rsrc-ref-lock-needs-to-be-irq-safe.patch blk-iocost-fix-lockdep-warning-on-blkcg-lock.patch ovl-fix-uninitialized-pointer-read-in-ovl_lookup_rea.patch net-mscc-fix-non-gpl-export-of-regmap-apis.patch +can-usb-esd_usb2-esd_usb2_rx_event-fix-the-interchange-of-the-can-rx-and-tx-error-counters.patch +ceph-correctly-handle-releasing-an-embedded-cap-flush.patch +dt-bindings-sifive-l2-cache-fix-select-matching.patch +riscv-ensure-the-value-of-fp-registers-in-the-core-dump-file-is-up-to-date.patch +powerpc-re-enable-arch_enable_split_pmd_ptlock.patch +mm-memory_hotplug-fix-potential-permanent-lru-cache-disable.patch +revert-btrfs-compression-don-t-try-to-compress-if-we-don-t-have-enough-pages.patch +net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-xsk_pool.patch +net-stmmac-fix-kernel-panic-due-to-null-pointer-dereference-of-buf-xdp.patch +drm-i915-fix-syncmap-memory-leak.patch +drm-i915-dp-drop-redundant-debug-print.patch +drm-amdgpu-cancel-delayed-work-when-gfxoff-is-disabled.patch +drm-amdgpu-use-the-preferred-pin-domain-after-the-check.patch +drm-amdgpu-fix-build-with-missing-pm_suspend_target_state-module-export.patch +revert-usb-serial-ch341-fix-character-loss-at-high-transfer-rates.patch +usb-serial-option-add-new-vid-pid-to-support-fibocom-fg150.patch +usb-renesas-xhci-prefer-firmware-loading-on-unknown-rom-state.patch +usb-typec-tcpm-raise-vdm_sm_running-flag-only-when-vdm-sm-is-running.patch +usb-dwc3-gadget-fix-dwc3_calc_trbs_left.patch +usb-dwc3-gadget-stop-ep0-transfers-during-pullup-disable.patch +scsi-core-fix-hang-of-freezing-queue-between-blocking-and-running-device.patch diff --git a/queue-5.13/usb-dwc3-gadget-fix-dwc3_calc_trbs_left.patch b/queue-5.13/usb-dwc3-gadget-fix-dwc3_calc_trbs_left.patch new file mode 100644 index 00000000000..ee2d33bccdf --- /dev/null +++ b/queue-5.13/usb-dwc3-gadget-fix-dwc3_calc_trbs_left.patch @@ -0,0 +1,60 @@ +From 51f1954ad853d01ba4dc2b35dee14d8490ee05a1 Mon Sep 17 00:00:00 2001 +From: Thinh Nguyen +Date: Thu, 19 Aug 2021 03:17:03 +0200 +Subject: usb: dwc3: gadget: Fix dwc3_calc_trbs_left() + +From: Thinh Nguyen + +commit 51f1954ad853d01ba4dc2b35dee14d8490ee05a1 upstream. + +We can't depend on the TRB's HWO bit to determine if the TRB ring is +"full". A TRB is only available when the driver had processed it, not +when the controller consumed and relinquished the TRB's ownership to the +driver. Otherwise, the driver may overwrite unprocessed TRBs. This can +happen when many transfer events accumulate and the system is slow to +process them and/or when there are too many small requests. + +If a request is in the started_list, that means there is one or more +unprocessed TRBs remained. Check this instead of the TRB's HWO bit +whether the TRB ring is full. + +Fixes: c4233573f6ee ("usb: dwc3: gadget: prepare TRBs on update transfers too") +Cc: +Acked-by: Felipe Balbi +Signed-off-by: Thinh Nguyen +Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/dwc3/gadget.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/usb/dwc3/gadget.c ++++ b/drivers/usb/dwc3/gadget.c +@@ -940,19 +940,19 @@ static struct dwc3_trb *dwc3_ep_prev_trb + + static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep) + { +- struct dwc3_trb *tmp; + u8 trbs_left; + + /* +- * If enqueue & dequeue are equal than it is either full or empty. +- * +- * One way to know for sure is if the TRB right before us has HWO bit +- * set or not. If it has, then we're definitely full and can't fit any +- * more transfers in our ring. ++ * If the enqueue & dequeue are equal then the TRB ring is either full ++ * or empty. It's considered full when there are DWC3_TRB_NUM-1 of TRBs ++ * pending to be processed by the driver. + */ + if (dep->trb_enqueue == dep->trb_dequeue) { +- tmp = dwc3_ep_prev_trb(dep, dep->trb_enqueue); +- if (tmp->ctrl & DWC3_TRB_CTRL_HWO) ++ /* ++ * If there is any request remained in the started_list at ++ * this point, that means there is no TRB available. ++ */ ++ if (!list_empty(&dep->started_list)) + return 0; + + return DWC3_TRB_NUM - 1; diff --git a/queue-5.13/usb-dwc3-gadget-stop-ep0-transfers-during-pullup-disable.patch b/queue-5.13/usb-dwc3-gadget-stop-ep0-transfers-during-pullup-disable.patch new file mode 100644 index 00000000000..170d0410eeb --- /dev/null +++ b/queue-5.13/usb-dwc3-gadget-stop-ep0-transfers-during-pullup-disable.patch @@ -0,0 +1,59 @@ +From 4a1e25c0a029b97ea4a3d423a6392bfacc3b2e39 Mon Sep 17 00:00:00 2001 +From: Wesley Cheng +Date: Tue, 24 Aug 2021 21:28:55 -0700 +Subject: usb: dwc3: gadget: Stop EP0 transfers during pullup disable + +From: Wesley Cheng + +commit 4a1e25c0a029b97ea4a3d423a6392bfacc3b2e39 upstream. + +During a USB cable disconnect, or soft disconnect scenario, a pending +SETUP transaction may not be completed, leading to the following +error: + + dwc3 a600000.dwc3: timed out waiting for SETUP phase + +If this occurs, then the entire pullup disable routine is skipped and +proper cleanup and halting of the controller does not complete. + +Instead of returning an error (which is ignored from the UDC +perspective), allow the pullup disable routine to continue, which +will also handle disabling of EP0/1. This will end any active +transfers as well. Ensure to clear any delayed_status also, as the +timeout could happen within the STATUS stage. + +Fixes: bb0147364850 ("usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to do so") +Cc: +Reviewed-by: Thinh Nguyen +Acked-by: Felipe Balbi +Signed-off-by: Wesley Cheng +Link: https://lore.kernel.org/r/20210825042855.7977-1-wcheng@codeaurora.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/dwc3/gadget.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/usb/dwc3/gadget.c ++++ b/drivers/usb/dwc3/gadget.c +@@ -2243,10 +2243,8 @@ static int dwc3_gadget_pullup(struct usb + + ret = wait_for_completion_timeout(&dwc->ep0_in_setup, + msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT)); +- if (ret == 0) { +- dev_err(dwc->dev, "timed out waiting for SETUP phase\n"); +- return -ETIMEDOUT; +- } ++ if (ret == 0) ++ dev_warn(dwc->dev, "timed out waiting for SETUP phase\n"); + } + + /* +@@ -2458,6 +2456,7 @@ static int __dwc3_gadget_start(struct dw + /* begin to receive SETUP packets */ + dwc->ep0state = EP0_SETUP_PHASE; + dwc->link_state = DWC3_LINK_STATE_SS_DIS; ++ dwc->delayed_status = false; + dwc3_ep0_out_start(dwc); + + dwc3_gadget_enable_irq(dwc); diff --git a/queue-5.13/usb-renesas-xhci-prefer-firmware-loading-on-unknown-rom-state.patch b/queue-5.13/usb-renesas-xhci-prefer-firmware-loading-on-unknown-rom-state.patch new file mode 100644 index 00000000000..4a792ff51f6 --- /dev/null +++ b/queue-5.13/usb-renesas-xhci-prefer-firmware-loading-on-unknown-rom-state.patch @@ -0,0 +1,123 @@ +From c82cacd2f1e622a461a77d275a75d7e19e7635a3 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 26 Aug 2021 14:41:27 +0200 +Subject: usb: renesas-xhci: Prefer firmware loading on unknown ROM state + +From: Takashi Iwai + +commit c82cacd2f1e622a461a77d275a75d7e19e7635a3 upstream. + +The recent attempt to handle an unknown ROM state in the commit +d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state") +resulted in a regression and reverted later by the commit 44cf53602f5a +("Revert "usb: renesas-xhci: Fix handling of unknown ROM state""). +The problem of the former fix was that it treated the failure of +firmware loading as a fatal error. Since the firmware files aren't +included in the standard linux-firmware tree, most users don't have +them, hence they got the non-working system after that. The revert +fixed the regression, but also it didn't make the firmware loading +triggered even on the devices that do need it. So we need still a fix +for them. + +This is another attempt to handle the unknown ROM state. Like the +previous fix, this also tries to load the firmware when ROM shows +unknown state. In this patch, however, the failure of a firmware +loading (such as a missing firmware file) isn't handled as a fatal +error any longer when ROM has been already detected, but it falls back +to the ROM mode like before. The error is returned only when no ROM +is detected and the firmware loading failed. + +Along with it, for simplifying the code flow, the detection and the +check of ROM is factored out from renesas_fw_check_running() and done +in the caller side, renesas_xhci_check_request_fw(). It avoids the +redundant ROM checks. + +The patch was tested on Lenovo Thinkpad T14 gen (BIOS 1.34). Also it +was confirmed that no regression is seen on another Thinkpad T14 +machine that has worked without the patch, too. + +Fixes: 44cf53602f5a ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state"") +Cc: stable +Signed-off-by: Takashi Iwai +BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1189207 +Link: https://lore.kernel.org/r/20210826124127.14789-1-tiwai@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci-renesas.c | 35 +++++++++++++++++++---------- + 1 file changed, 23 insertions(+), 12 deletions(-) + +diff --git a/drivers/usb/host/xhci-pci-renesas.c b/drivers/usb/host/xhci-pci-renesas.c +index 5923844ed821..ef5e91a5542d 100644 +--- a/drivers/usb/host/xhci-pci-renesas.c ++++ b/drivers/usb/host/xhci-pci-renesas.c +@@ -207,7 +207,8 @@ static int renesas_check_rom_state(struct pci_dev *pdev) + return 0; + + case RENESAS_ROM_STATUS_NO_RESULT: /* No result yet */ +- return 0; ++ dev_dbg(&pdev->dev, "Unknown ROM status ...\n"); ++ return -ENOENT; + + case RENESAS_ROM_STATUS_ERROR: /* Error State */ + default: /* All other states are marked as "Reserved states" */ +@@ -224,14 +225,6 @@ static int renesas_fw_check_running(struct pci_dev *pdev) + u8 fw_state; + int err; + +- /* Check if device has ROM and loaded, if so skip everything */ +- err = renesas_check_rom(pdev); +- if (err) { /* we have rom */ +- err = renesas_check_rom_state(pdev); +- if (!err) +- return err; +- } +- + /* + * Test if the device is actually needing the firmware. As most + * BIOSes will initialize the device for us. If the device is +@@ -591,21 +584,39 @@ int renesas_xhci_check_request_fw(struct pci_dev *pdev, + (struct xhci_driver_data *)id->driver_data; + const char *fw_name = driver_data->firmware; + const struct firmware *fw; ++ bool has_rom; + int err; + ++ /* Check if device has ROM and loaded, if so skip everything */ ++ has_rom = renesas_check_rom(pdev); ++ if (has_rom) { ++ err = renesas_check_rom_state(pdev); ++ if (!err) ++ return 0; ++ else if (err != -ENOENT) ++ has_rom = false; ++ } ++ + err = renesas_fw_check_running(pdev); + /* Continue ahead, if the firmware is already running. */ + if (err == 0) + return 0; + ++ /* no firmware interface available */ + if (err != 1) +- return err; ++ return has_rom ? 0 : err; + + pci_dev_get(pdev); +- err = request_firmware(&fw, fw_name, &pdev->dev); ++ err = firmware_request_nowarn(&fw, fw_name, &pdev->dev); + pci_dev_put(pdev); + if (err) { +- dev_err(&pdev->dev, "request_firmware failed: %d\n", err); ++ if (has_rom) { ++ dev_info(&pdev->dev, "failed to load firmware %s, fallback to ROM\n", ++ fw_name); ++ return 0; ++ } ++ dev_err(&pdev->dev, "failed to load firmware %s: %d\n", ++ fw_name, err); + return err; + } + +-- +2.32.0 + diff --git a/queue-5.13/usb-serial-option-add-new-vid-pid-to-support-fibocom-fg150.patch b/queue-5.13/usb-serial-option-add-new-vid-pid-to-support-fibocom-fg150.patch new file mode 100644 index 00000000000..5bbe769ca81 --- /dev/null +++ b/queue-5.13/usb-serial-option-add-new-vid-pid-to-support-fibocom-fg150.patch @@ -0,0 +1,278 @@ +From 2829a4e3cf3a6ac2fa3cdb681b37574630fb9c1a Mon Sep 17 00:00:00 2001 +From: Zhengjun Zhang +Date: Mon, 9 Aug 2021 21:35:53 +0800 +Subject: USB: serial: option: add new VID/PID to support Fibocom FG150 + +From: Zhengjun Zhang + +commit 2829a4e3cf3a6ac2fa3cdb681b37574630fb9c1a upstream. + +Fibocom FG150 is a 5G module based on Qualcomm SDX55 platform, +support Sub-6G band. + +Here are the outputs of lsusb -v and usb-devices: + +> T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 +> D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 +> P: Vendor=2cb7 ProdID=010b Rev=04.14 +> S: Manufacturer=Fibocom +> S: Product=Fibocom Modem_SN:XXXXXXXX +> S: SerialNumber=XXXXXXXX +> C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA +> I: If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host +> I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host +> I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) +> I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) +> I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) + +> Bus 002 Device 002: ID 2cb7:010b Fibocom Fibocom Modem_SN:XXXXXXXX +> Device Descriptor: +> bLength 18 +> bDescriptorType 1 +> bcdUSB 3.20 +> bDeviceClass 0 +> bDeviceSubClass 0 +> bDeviceProtocol 0 +> bMaxPacketSize0 9 +> idVendor 0x2cb7 Fibocom +> idProduct 0x010b +> bcdDevice 4.14 +> iManufacturer 1 Fibocom +> iProduct 2 Fibocom Modem_SN:XXXXXXXX +> iSerial 3 XXXXXXXX +> bNumConfigurations 1 +> Configuration Descriptor: +> bLength 9 +> bDescriptorType 2 +> wTotalLength 0x00e6 +> bNumInterfaces 5 +> bConfigurationValue 1 +> iConfiguration 4 RNDIS_DUN_DIAG_ADB +> bmAttributes 0xa0 +> (Bus Powered) +> Remote Wakeup +> MaxPower 896mA +> Interface Association: +> bLength 8 +> bDescriptorType 11 +> bFirstInterface 0 +> bInterfaceCount 2 +> bFunctionClass 239 Miscellaneous Device +> bFunctionSubClass 4 +> bFunctionProtocol 1 +> iFunction 7 RNDIS +> Interface Descriptor: +> bLength 9 +> bDescriptorType 4 +> bInterfaceNumber 0 +> bAlternateSetting 0 +> bNumEndpoints 1 +> bInterfaceClass 239 Miscellaneous Device +> bInterfaceSubClass 4 +> bInterfaceProtocol 1 +> iInterface 0 +> ** UNRECOGNIZED: 05 24 00 10 01 +> ** UNRECOGNIZED: 05 24 01 00 01 +> ** UNRECOGNIZED: 04 24 02 00 +> ** UNRECOGNIZED: 05 24 06 00 01 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x81 EP 1 IN +> bmAttributes 3 +> Transfer Type Interrupt +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0008 1x 8 bytes +> bInterval 9 +> bMaxBurst 0 +> Interface Descriptor: +> bLength 9 +> bDescriptorType 4 +> bInterfaceNumber 1 +> bAlternateSetting 0 +> bNumEndpoints 2 +> bInterfaceClass 10 CDC Data +> bInterfaceSubClass 0 +> bInterfaceProtocol 0 +> iInterface 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x8e EP 14 IN +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 6 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x0f EP 15 OUT +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 6 +> Interface Descriptor: +> bLength 9 +> bDescriptorType 4 +> bInterfaceNumber 2 +> bAlternateSetting 0 +> bNumEndpoints 3 +> bInterfaceClass 255 Vendor Specific Class +> bInterfaceSubClass 0 +> bInterfaceProtocol 0 +> iInterface 0 +> ** UNRECOGNIZED: 05 24 00 10 01 +> ** UNRECOGNIZED: 05 24 01 00 00 +> ** UNRECOGNIZED: 04 24 02 02 +> ** UNRECOGNIZED: 05 24 06 00 00 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x83 EP 3 IN +> bmAttributes 3 +> Transfer Type Interrupt +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x000a 1x 10 bytes +> bInterval 9 +> bMaxBurst 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x82 EP 2 IN +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x01 EP 1 OUT +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 0 +> Interface Descriptor: +> bLength 9 +> bDescriptorType 4 +> bInterfaceNumber 3 +> bAlternateSetting 0 +> bNumEndpoints 2 +> bInterfaceClass 255 Vendor Specific Class +> bInterfaceSubClass 255 Vendor Specific Subclass +> bInterfaceProtocol 48 +> iInterface 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x84 EP 4 IN +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x02 EP 2 OUT +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 0 +> Interface Descriptor: +> bLength 9 +> bDescriptorType 4 +> bInterfaceNumber 4 +> bAlternateSetting 0 +> bNumEndpoints 2 +> bInterfaceClass 255 Vendor Specific Class +> bInterfaceSubClass 66 +> bInterfaceProtocol 1 +> iInterface 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x03 EP 3 OUT +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 0 +> Endpoint Descriptor: +> bLength 7 +> bDescriptorType 5 +> bEndpointAddress 0x85 EP 5 IN +> bmAttributes 2 +> Transfer Type Bulk +> Synch Type None +> Usage Type Data +> wMaxPacketSize 0x0400 1x 1024 bytes +> bInterval 0 +> bMaxBurst 0 +> Binary Object Store Descriptor: +> bLength 5 +> bDescriptorType 15 +> wTotalLength 0x0016 +> bNumDeviceCaps 2 +> USB 2.0 Extension Device Capability: +> bLength 7 +> bDescriptorType 16 +> bDevCapabilityType 2 +> bmAttributes 0x00000006 +> BESL Link Power Management (LPM) Supported +> SuperSpeed USB Device Capability: +> bLength 10 +> bDescriptorType 16 +> bDevCapabilityType 3 +> bmAttributes 0x00 +> wSpeedsSupported 0x000f +> Device can operate at Low Speed (1Mbps) +> Device can operate at Full Speed (12Mbps) +> Device can operate at High Speed (480Mbps) +> Device can operate at SuperSpeed (5Gbps) +> bFunctionalitySupport 1 +> Lowest fully-functional device speed is Full Speed (12Mbps) +> bU1DevExitLat 1 micro seconds +> bU2DevExitLat 500 micro seconds +> Device Status: 0x0000 +> (Bus Powered) + +Signed-off-by: Zhengjun Zhang +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/option.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/usb/serial/option.c ++++ b/drivers/usb/serial/option.c +@@ -2074,6 +2074,8 @@ static const struct usb_device_id option + .driver_info = RSVD(4) | RSVD(5) }, + { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x0105, 0xff), /* Fibocom NL678 series */ + .driver_info = RSVD(6) }, ++ { USB_DEVICE_AND_INTERFACE_INFO(0x2cb7, 0x010b, 0xff, 0xff, 0x30) }, /* Fibocom FG150 Diag */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x2cb7, 0x010b, 0xff, 0, 0) }, /* Fibocom FG150 AT */ + { USB_DEVICE_INTERFACE_CLASS(0x2cb7, 0x01a0, 0xff) }, /* Fibocom NL668-AM/NL652-EU (laptop MBIM) */ + { USB_DEVICE_INTERFACE_CLASS(0x2df3, 0x9d03, 0xff) }, /* LongSung M5710 */ + { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1404, 0xff) }, /* GosunCn GM500 RNDIS */ diff --git a/queue-5.13/usb-typec-tcpm-raise-vdm_sm_running-flag-only-when-vdm-sm-is-running.patch b/queue-5.13/usb-typec-tcpm-raise-vdm_sm_running-flag-only-when-vdm-sm-is-running.patch new file mode 100644 index 00000000000..c223634208f --- /dev/null +++ b/queue-5.13/usb-typec-tcpm-raise-vdm_sm_running-flag-only-when-vdm-sm-is-running.patch @@ -0,0 +1,302 @@ +From ef52b4a9fcc24e17e81cc60357e6107ae4e9c48e Mon Sep 17 00:00:00 2001 +From: Kyle Tso +Date: Thu, 26 Aug 2021 20:42:01 +0800 +Subject: usb: typec: tcpm: Raise vdm_sm_running flag only when VDM SM is running + +From: Kyle Tso + +commit ef52b4a9fcc24e17e81cc60357e6107ae4e9c48e upstream. + +If the port is going to send Discover_Identity Message, vdm_sm_running +flag was intentionally set before entering Ready States in order to +avoid the conflict because the port and the port partner might start +AMS at almost the same time after entering Ready States. + +However, the original design has a problem. When the port is doing +DR_SWAP from Device to Host, it raises the flag. Later in the +tcpm_send_discover_work, the flag blocks the procedure of sending the +Discover_Identity and it might never be cleared until disconnection. + +Since there exists another flag send_discover representing that the port +is going to send Discover_Identity or not, it is enough to use that flag +to prevent the conflict. Also change the timing of the set/clear of +vdm_sm_running to indicate whether the VDM SM is actually running or +not. + +Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work") +Cc: stable +Cc: Badhri Jagan Sridharan +Reviewed-by: Guenter Roeck +Acked-by: Heikki Krogerus +Signed-off-by: Kyle Tso +Link: https://lore.kernel.org/r/20210826124201.1562502-1-kyletso@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 81 +++++++++++++++++++----------------------- + 1 file changed, 38 insertions(+), 43 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -341,6 +341,7 @@ struct tcpm_port { + bool vbus_source; + bool vbus_charge; + ++ /* Set to true when Discover_Identity Command is expected to be sent in Ready states. */ + bool send_discover; + bool op_vsafe5v; + +@@ -370,6 +371,7 @@ struct tcpm_port { + struct hrtimer send_discover_timer; + struct kthread_work send_discover_work; + bool state_machine_running; ++ /* Set to true when VDM State Machine has following actions. */ + bool vdm_sm_running; + + struct completion tx_complete; +@@ -1403,6 +1405,7 @@ static void tcpm_queue_vdm(struct tcpm_p + /* Set ready, vdm state machine will actually send */ + port->vdm_retries = 0; + port->vdm_state = VDM_STATE_READY; ++ port->vdm_sm_running = true; + + mod_vdm_delayed_work(port, 0); + } +@@ -1645,7 +1648,6 @@ static int tcpm_pd_svdm(struct tcpm_port + rlen = 1; + } else { + tcpm_register_partner_altmodes(port); +- port->vdm_sm_running = false; + } + break; + case CMD_ENTER_MODE: +@@ -1693,14 +1695,12 @@ static int tcpm_pd_svdm(struct tcpm_port + (VDO_SVDM_VERS(svdm_version)); + break; + } +- port->vdm_sm_running = false; + break; + default: + response[0] = p[0] | VDO_CMDT(CMDT_RSP_NAK); + rlen = 1; + response[0] = (response[0] & ~VDO_SVDM_VERS_MASK) | + (VDO_SVDM_VERS(svdm_version)); +- port->vdm_sm_running = false; + break; + } + +@@ -1741,6 +1741,20 @@ static void tcpm_handle_vdm_request(stru + } + + if (PD_VDO_SVDM(p[0]) && (adev || tcpm_vdm_ams(port) || port->nr_snk_vdo)) { ++ /* ++ * Here a SVDM is received (INIT or RSP or unknown). Set the vdm_sm_running in ++ * advance because we are dropping the lock but may send VDMs soon. ++ * For the cases of INIT received: ++ * - If no response to send, it will be cleared later in this function. ++ * - If there are responses to send, it will be cleared in the state machine. ++ * For the cases of RSP received: ++ * - If no further INIT to send, it will be cleared later in this function. ++ * - Otherwise, it will be cleared in the state machine if timeout or it will go ++ * back here until no further INIT to send. ++ * For the cases of unknown type received: ++ * - We will send NAK and the flag will be cleared in the state machine. ++ */ ++ port->vdm_sm_running = true; + rlen = tcpm_pd_svdm(port, adev, p, cnt, response, &adev_action); + } else { + if (port->negotiated_rev >= PD_REV30) +@@ -1809,6 +1823,8 @@ static void tcpm_handle_vdm_request(stru + + if (rlen > 0) + tcpm_queue_vdm(port, response[0], &response[1], rlen - 1); ++ else ++ port->vdm_sm_running = false; + } + + static void tcpm_send_vdm(struct tcpm_port *port, u32 vid, int cmd, +@@ -1874,8 +1890,10 @@ static void vdm_run_state_machine(struct + * if there's traffic or we're not in PDO ready state don't send + * a VDM. + */ +- if (port->state != SRC_READY && port->state != SNK_READY) ++ if (port->state != SRC_READY && port->state != SNK_READY) { ++ port->vdm_sm_running = false; + break; ++ } + + /* TODO: AMS operation for Unstructured VDM */ + if (PD_VDO_SVDM(vdo_hdr) && PD_VDO_CMDT(vdo_hdr) == CMDT_INIT) { +@@ -2528,10 +2546,6 @@ static void tcpm_pd_ctrl_request(struct + TYPEC_PWR_MODE_PD, + port->pps_data.active, + port->supply_voltage); +- /* Set VDM running flag ASAP */ +- if (port->data_role == TYPEC_HOST && +- port->send_discover) +- port->vdm_sm_running = true; + tcpm_set_state(port, SNK_READY, 0); + } else { + /* +@@ -2569,14 +2583,10 @@ static void tcpm_pd_ctrl_request(struct + switch (port->state) { + case SNK_NEGOTIATE_CAPABILITIES: + /* USB PD specification, Figure 8-43 */ +- if (port->explicit_contract) { ++ if (port->explicit_contract) + next_state = SNK_READY; +- if (port->data_role == TYPEC_HOST && +- port->send_discover) +- port->vdm_sm_running = true; +- } else { ++ else + next_state = SNK_WAIT_CAPABILITIES; +- } + + /* Threshold was relaxed before sending Request. Restore it back. */ + tcpm_set_auto_vbus_discharge_threshold(port, TYPEC_PWR_MODE_PD, +@@ -2591,10 +2601,6 @@ static void tcpm_pd_ctrl_request(struct + port->pps_status = (type == PD_CTRL_WAIT ? + -EAGAIN : -EOPNOTSUPP); + +- if (port->data_role == TYPEC_HOST && +- port->send_discover) +- port->vdm_sm_running = true; +- + /* Threshold was relaxed before sending Request. Restore it back. */ + tcpm_set_auto_vbus_discharge_threshold(port, TYPEC_PWR_MODE_PD, + port->pps_data.active, +@@ -2670,10 +2676,6 @@ static void tcpm_pd_ctrl_request(struct + } + break; + case DR_SWAP_SEND: +- if (port->data_role == TYPEC_DEVICE && +- port->send_discover) +- port->vdm_sm_running = true; +- + tcpm_set_state(port, DR_SWAP_CHANGE_DR, 0); + break; + case PR_SWAP_SEND: +@@ -2711,7 +2713,7 @@ static void tcpm_pd_ctrl_request(struct + PD_MSG_CTRL_NOT_SUPP, + NONE_AMS); + } else { +- if (port->vdm_sm_running) { ++ if (port->send_discover) { + tcpm_queue_message(port, PD_MSG_CTRL_WAIT); + break; + } +@@ -2727,7 +2729,7 @@ static void tcpm_pd_ctrl_request(struct + PD_MSG_CTRL_NOT_SUPP, + NONE_AMS); + } else { +- if (port->vdm_sm_running) { ++ if (port->send_discover) { + tcpm_queue_message(port, PD_MSG_CTRL_WAIT); + break; + } +@@ -2736,7 +2738,7 @@ static void tcpm_pd_ctrl_request(struct + } + break; + case PD_CTRL_VCONN_SWAP: +- if (port->vdm_sm_running) { ++ if (port->send_discover) { + tcpm_queue_message(port, PD_MSG_CTRL_WAIT); + break; + } +@@ -4470,18 +4472,20 @@ static void run_state_machine(struct tcp + /* DR_Swap states */ + case DR_SWAP_SEND: + tcpm_pd_send_control(port, PD_CTRL_DR_SWAP); ++ if (port->data_role == TYPEC_DEVICE || port->negotiated_rev > PD_REV20) ++ port->send_discover = true; + tcpm_set_state_cond(port, DR_SWAP_SEND_TIMEOUT, + PD_T_SENDER_RESPONSE); + break; + case DR_SWAP_ACCEPT: + tcpm_pd_send_control(port, PD_CTRL_ACCEPT); +- /* Set VDM state machine running flag ASAP */ +- if (port->data_role == TYPEC_DEVICE && port->send_discover) +- port->vdm_sm_running = true; ++ if (port->data_role == TYPEC_DEVICE || port->negotiated_rev > PD_REV20) ++ port->send_discover = true; + tcpm_set_state_cond(port, DR_SWAP_CHANGE_DR, 0); + break; + case DR_SWAP_SEND_TIMEOUT: + tcpm_swap_complete(port, -ETIMEDOUT); ++ port->send_discover = false; + tcpm_ams_finish(port); + tcpm_set_state(port, ready_state(port), 0); + break; +@@ -4493,7 +4497,6 @@ static void run_state_machine(struct tcp + } else { + tcpm_set_roles(port, true, port->pwr_role, + TYPEC_HOST); +- port->send_discover = true; + } + tcpm_ams_finish(port); + tcpm_set_state(port, ready_state(port), 0); +@@ -4633,8 +4636,6 @@ static void run_state_machine(struct tcp + break; + case VCONN_SWAP_SEND_TIMEOUT: + tcpm_swap_complete(port, -ETIMEDOUT); +- if (port->data_role == TYPEC_HOST && port->send_discover) +- port->vdm_sm_running = true; + tcpm_set_state(port, ready_state(port), 0); + break; + case VCONN_SWAP_START: +@@ -4650,14 +4651,10 @@ static void run_state_machine(struct tcp + case VCONN_SWAP_TURN_ON_VCONN: + tcpm_set_vconn(port, true); + tcpm_pd_send_control(port, PD_CTRL_PS_RDY); +- if (port->data_role == TYPEC_HOST && port->send_discover) +- port->vdm_sm_running = true; + tcpm_set_state(port, ready_state(port), 0); + break; + case VCONN_SWAP_TURN_OFF_VCONN: + tcpm_set_vconn(port, false); +- if (port->data_role == TYPEC_HOST && port->send_discover) +- port->vdm_sm_running = true; + tcpm_set_state(port, ready_state(port), 0); + break; + +@@ -4665,8 +4662,6 @@ static void run_state_machine(struct tcp + case PR_SWAP_CANCEL: + case VCONN_SWAP_CANCEL: + tcpm_swap_complete(port, port->swap_status); +- if (port->data_role == TYPEC_HOST && port->send_discover) +- port->vdm_sm_running = true; + if (port->pwr_role == TYPEC_SOURCE) + tcpm_set_state(port, SRC_READY, 0); + else +@@ -5016,9 +5011,6 @@ static void _tcpm_pd_vbus_on(struct tcpm + switch (port->state) { + case SNK_TRANSITION_SINK_VBUS: + port->explicit_contract = true; +- /* Set the VDM flag ASAP */ +- if (port->data_role == TYPEC_HOST && port->send_discover) +- port->vdm_sm_running = true; + tcpm_set_state(port, SNK_READY, 0); + break; + case SNK_DISCOVERY: +@@ -5412,15 +5404,18 @@ static void tcpm_send_discover_work(stru + if (!port->send_discover) + goto unlock; + ++ if (port->data_role == TYPEC_DEVICE && port->negotiated_rev < PD_REV30) { ++ port->send_discover = false; ++ goto unlock; ++ } ++ + /* Retry if the port is not idle */ + if ((port->state != SRC_READY && port->state != SNK_READY) || port->vdm_sm_running) { + mod_send_discover_delayed_work(port, SEND_DISCOVER_RETRY_MS); + goto unlock; + } + +- /* Only send the Message if the port is host for PD rev2.0 */ +- if (port->data_role == TYPEC_HOST || port->negotiated_rev > PD_REV20) +- tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0); ++ tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0); + + unlock: + mutex_unlock(&port->lock); -- 2.47.3