From: Greg Kroah-Hartman Date: Mon, 17 May 2021 08:28:20 +0000 (+0200) Subject: 5.11-stable patches X-Git-Tag: v5.4.120~53 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2eb406fd78ebe00b55ed430f9458873acc63d46a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.11-stable patches added patches: cdc-wdm-untangle-a-circular-dependency-between-callback-and-softint.patch iio-core-fix-ioctl-handlers-removal.patch iio-gyro-mpu3050-fix-reported-temperature-value.patch iio-tsl2583-fix-division-by-a-zero-lux_val.patch kvm-nvmx-always-make-an-attempt-to-map-evmcs-after-migration.patch kvm-x86-emulate-rdpid-only-if-rdtscp-is-supported.patch kvm-x86-move-rdpid-emulation-intercept-to-its-own-enum.patch xen-gntdev-fix-gntdev_mmap-error-exit-path.patch xhci-add-reset-resume-quirk-for-amd-xhci-controller.patch xhci-do-not-use-gfp_kernel-in-potentially-atomic-context.patch xhci-pci-allow-host-runtime-pm-as-default-for-intel-alder-lake-xhci.patch --- diff --git a/queue-5.11/cdc-wdm-untangle-a-circular-dependency-between-callback-and-softint.patch b/queue-5.11/cdc-wdm-untangle-a-circular-dependency-between-callback-and-softint.patch new file mode 100644 index 00000000000..a651be62955 --- /dev/null +++ b/queue-5.11/cdc-wdm-untangle-a-circular-dependency-between-callback-and-softint.patch @@ -0,0 +1,105 @@ +From 18abf874367456540846319574864e6ff32752e2 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Mon, 26 Apr 2021 11:26:22 +0200 +Subject: cdc-wdm: untangle a circular dependency between callback and softint + +From: Oliver Neukum + +commit 18abf874367456540846319574864e6ff32752e2 upstream. + +We have a cycle of callbacks scheduling works which submit +URBs with those callbacks. This needs to be blocked, stopped +and unblocked to untangle the circle. + +Signed-off-by: Oliver Neukum +Link: https://lore.kernel.org/r/20210426092622.20433-1-oneukum@suse.com +Cc: stable +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/class/cdc-wdm.c | 30 ++++++++++++++++++++++-------- + 1 file changed, 22 insertions(+), 8 deletions(-) + +--- a/drivers/usb/class/cdc-wdm.c ++++ b/drivers/usb/class/cdc-wdm.c +@@ -321,12 +321,23 @@ exit: + + } + +-static void kill_urbs(struct wdm_device *desc) ++static void poison_urbs(struct wdm_device *desc) + { + /* the order here is essential */ +- usb_kill_urb(desc->command); +- usb_kill_urb(desc->validity); +- usb_kill_urb(desc->response); ++ usb_poison_urb(desc->command); ++ usb_poison_urb(desc->validity); ++ usb_poison_urb(desc->response); ++} ++ ++static void unpoison_urbs(struct wdm_device *desc) ++{ ++ /* ++ * the order here is not essential ++ * it is symmetrical just to be nice ++ */ ++ usb_unpoison_urb(desc->response); ++ usb_unpoison_urb(desc->validity); ++ usb_unpoison_urb(desc->command); + } + + static void free_urbs(struct wdm_device *desc) +@@ -741,11 +752,12 @@ static int wdm_release(struct inode *ino + if (!desc->count) { + if (!test_bit(WDM_DISCONNECTING, &desc->flags)) { + dev_dbg(&desc->intf->dev, "wdm_release: cleanup\n"); +- kill_urbs(desc); ++ poison_urbs(desc); + spin_lock_irq(&desc->iuspin); + desc->resp_count = 0; + spin_unlock_irq(&desc->iuspin); + desc->manage_power(desc->intf, 0); ++ unpoison_urbs(desc); + } else { + /* must avoid dev_printk here as desc->intf is invalid */ + pr_debug(KBUILD_MODNAME " %s: device gone - cleaning up\n", __func__); +@@ -1037,9 +1049,9 @@ static void wdm_disconnect(struct usb_in + wake_up_all(&desc->wait); + mutex_lock(&desc->rlock); + mutex_lock(&desc->wlock); ++ poison_urbs(desc); + cancel_work_sync(&desc->rxwork); + cancel_work_sync(&desc->service_outs_intr); +- kill_urbs(desc); + mutex_unlock(&desc->wlock); + mutex_unlock(&desc->rlock); + +@@ -1080,9 +1092,10 @@ static int wdm_suspend(struct usb_interf + set_bit(WDM_SUSPENDING, &desc->flags); + spin_unlock_irq(&desc->iuspin); + /* callback submits work - order is essential */ +- kill_urbs(desc); ++ poison_urbs(desc); + cancel_work_sync(&desc->rxwork); + cancel_work_sync(&desc->service_outs_intr); ++ unpoison_urbs(desc); + } + if (!PMSG_IS_AUTO(message)) { + mutex_unlock(&desc->wlock); +@@ -1140,7 +1153,7 @@ static int wdm_pre_reset(struct usb_inte + wake_up_all(&desc->wait); + mutex_lock(&desc->rlock); + mutex_lock(&desc->wlock); +- kill_urbs(desc); ++ poison_urbs(desc); + cancel_work_sync(&desc->rxwork); + cancel_work_sync(&desc->service_outs_intr); + return 0; +@@ -1151,6 +1164,7 @@ static int wdm_post_reset(struct usb_int + struct wdm_device *desc = wdm_find_device(intf); + int rv; + ++ unpoison_urbs(desc); + clear_bit(WDM_OVERFLOW, &desc->flags); + clear_bit(WDM_RESETTING, &desc->flags); + rv = recover_from_urb_loss(desc); diff --git a/queue-5.11/iio-core-fix-ioctl-handlers-removal.patch b/queue-5.11/iio-core-fix-ioctl-handlers-removal.patch new file mode 100644 index 00000000000..96757a1bfee --- /dev/null +++ b/queue-5.11/iio-core-fix-ioctl-handlers-removal.patch @@ -0,0 +1,51 @@ +From 901f84de0e16bde10a72d7eb2f2eb73fcde8fa1a Mon Sep 17 00:00:00 2001 +From: Tomasz Duszynski +Date: Fri, 23 Apr 2021 10:02:44 +0200 +Subject: iio: core: fix ioctl handlers removal + +From: Tomasz Duszynski + +commit 901f84de0e16bde10a72d7eb2f2eb73fcde8fa1a upstream. + +Currently ioctl handlers are removed twice. For the first time during +iio_device_unregister() then later on inside +iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask(). +Double free leads to kernel panic. + +Fix this by not touching ioctl handlers list directly but rather +letting code responsible for registration call the matching cleanup +routine itself. + +Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev") +Signed-off-by: Tomasz Duszynski +Acked-by: Alexandru Ardelean +Cc: +Link: https://lore.kernel.org/r/20210423080244.2790-1-tomasz.duszynski@octakon.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/industrialio-core.c | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/drivers/iio/industrialio-core.c ++++ b/drivers/iio/industrialio-core.c +@@ -1827,9 +1827,6 @@ EXPORT_SYMBOL(__iio_device_register); + **/ + void iio_device_unregister(struct iio_dev *indio_dev) + { +- struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev); +- struct iio_ioctl_handler *h, *t; +- + cdev_device_del(&indio_dev->chrdev, &indio_dev->dev); + + mutex_lock(&indio_dev->info_exist_lock); +@@ -1840,9 +1837,6 @@ void iio_device_unregister(struct iio_de + + indio_dev->info = NULL; + +- list_for_each_entry_safe(h, t, &iio_dev_opaque->ioctl_handlers, entry) +- list_del(&h->entry); +- + iio_device_wakeup_eventset(indio_dev); + iio_buffer_wakeup_poll(indio_dev); + diff --git a/queue-5.11/iio-gyro-mpu3050-fix-reported-temperature-value.patch b/queue-5.11/iio-gyro-mpu3050-fix-reported-temperature-value.patch new file mode 100644 index 00000000000..9958cf5f5ba --- /dev/null +++ b/queue-5.11/iio-gyro-mpu3050-fix-reported-temperature-value.patch @@ -0,0 +1,59 @@ +From f73c730774d88a14d7b60feee6d0e13570f99499 Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +Date: Fri, 23 Apr 2021 05:09:59 +0300 +Subject: iio: gyro: mpu3050: Fix reported temperature value + +From: Dmitry Osipenko + +commit f73c730774d88a14d7b60feee6d0e13570f99499 upstream. + +The raw temperature value is a 16-bit signed integer. The sign casting +is missing in the code, which results in a wrong temperature reported +by userspace tools, fix it. + +Cc: stable@vger.kernel.org +Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") +Datasheet: https://www.cdiweb.com/datasheets/invensense/mpu-3000a.pdf +Tested-by: Maxim Schwalm # Asus TF700T +Tested-by: Svyatoslav Ryhel # Asus TF201 +Reported-by: Svyatoslav Ryhel +Reviewed-by: Andy Shevchenko +Reviewed-by: Linus Walleij +Signed-off-by: Dmitry Osipenko +Acked-by: Jean-Baptiste Maneyrol +Link: https://lore.kernel.org/r/20210423020959.5023-1-digetx@gmail.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/gyro/mpu3050-core.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +--- a/drivers/iio/gyro/mpu3050-core.c ++++ b/drivers/iio/gyro/mpu3050-core.c +@@ -272,7 +272,16 @@ static int mpu3050_read_raw(struct iio_d + case IIO_CHAN_INFO_OFFSET: + switch (chan->type) { + case IIO_TEMP: +- /* The temperature scaling is (x+23000)/280 Celsius */ ++ /* ++ * The temperature scaling is (x+23000)/280 Celsius ++ * for the "best fit straight line" temperature range ++ * of -30C..85C. The 23000 includes room temperature ++ * offset of +35C, 280 is the precision scale and x is ++ * the 16-bit signed integer reported by hardware. ++ * ++ * Temperature value itself represents temperature of ++ * the sensor die. ++ */ + *val = 23000; + return IIO_VAL_INT; + default: +@@ -329,7 +338,7 @@ static int mpu3050_read_raw(struct iio_d + goto out_read_raw_unlock; + } + +- *val = be16_to_cpu(raw_val); ++ *val = (s16)be16_to_cpu(raw_val); + ret = IIO_VAL_INT; + + goto out_read_raw_unlock; diff --git a/queue-5.11/iio-tsl2583-fix-division-by-a-zero-lux_val.patch b/queue-5.11/iio-tsl2583-fix-division-by-a-zero-lux_val.patch new file mode 100644 index 00000000000..f3485a258ba --- /dev/null +++ b/queue-5.11/iio-tsl2583-fix-division-by-a-zero-lux_val.patch @@ -0,0 +1,45 @@ +From af0e1871d79cfbb91f732d2c6fa7558e45c31038 Mon Sep 17 00:00:00 2001 +From: Colin Ian King +Date: Fri, 7 May 2021 19:30:41 +0100 +Subject: iio: tsl2583: Fix division by a zero lux_val + +From: Colin Ian King + +commit af0e1871d79cfbb91f732d2c6fa7558e45c31038 upstream. + +The lux_val returned from tsl2583_get_lux can potentially be zero, +so check for this to avoid a division by zero and an overflowed +gain_trim_val. + +Fixes clang scan-build warning: + +drivers/iio/light/tsl2583.c:345:40: warning: Either the +condition 'lux_val<0' is redundant or there is division +by zero at line 345. [zerodivcond] + +Fixes: ac4f6eee8fe8 ("staging: iio: TAOS tsl258x: Device driver") +Signed-off-by: Colin Ian King +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/tsl2583.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/iio/light/tsl2583.c ++++ b/drivers/iio/light/tsl2583.c +@@ -341,6 +341,14 @@ static int tsl2583_als_calibrate(struct + return lux_val; + } + ++ /* Avoid division by zero of lux_value later on */ ++ if (lux_val == 0) { ++ dev_err(&chip->client->dev, ++ "%s: lux_val of 0 will produce out of range trim_value\n", ++ __func__); ++ return -ENODATA; ++ } ++ + gain_trim_val = (unsigned int)(((chip->als_settings.als_cal_target) + * chip->als_settings.als_gain_trim) / lux_val); + if ((gain_trim_val < 250) || (gain_trim_val > 4000)) { diff --git a/queue-5.11/kvm-nvmx-always-make-an-attempt-to-map-evmcs-after-migration.patch b/queue-5.11/kvm-nvmx-always-make-an-attempt-to-map-evmcs-after-migration.patch new file mode 100644 index 00000000000..e1a0766a499 --- /dev/null +++ b/queue-5.11/kvm-nvmx-always-make-an-attempt-to-map-evmcs-after-migration.patch @@ -0,0 +1,98 @@ +From f5c7e8425f18fdb9bdb7d13340651d7876890329 Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Mon, 3 May 2021 17:08:51 +0200 +Subject: KVM: nVMX: Always make an attempt to map eVMCS after migration + +From: Vitaly Kuznetsov + +commit f5c7e8425f18fdb9bdb7d13340651d7876890329 upstream. + +When enlightened VMCS is in use and nested state is migrated with +vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs +page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' +and we can't read it from VP assist page because userspace may decide +to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state +(and QEMU, for example, does exactly that). To make sure eVMCS is +mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES +request. + +Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES +on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to +nested_vmx_vmexit() to make sure MSR permission bitmap is not switched +when an immediate exit from L2 to L1 happens right after migration (caused +by a pending event, for example). Unfortunately, in the exact same +situation we still need to have eVMCS mapped so +nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. + +As a band-aid, restore nested_get_evmcs_page() when clearing +KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far +from being ideal as we can't easily propagate possible failures and even if +we could, this is most likely already too late to do so. The whole +'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration +seems to be fragile as we diverge too much from the 'native' path when +vmptr loading happens on vmx_set_nested_state(). + +Fixes: f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") +Signed-off-by: Vitaly Kuznetsov +Message-Id: <20210503150854.1144255-2-vkuznets@redhat.com> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/nested.c | 29 +++++++++++++++++++---------- + 1 file changed, 19 insertions(+), 10 deletions(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -3140,15 +3140,8 @@ static bool nested_get_evmcs_page(struct + nested_vmx_handle_enlightened_vmptrld(vcpu, false); + + if (evmptrld_status == EVMPTRLD_VMFAIL || +- evmptrld_status == EVMPTRLD_ERROR) { +- pr_debug_ratelimited("%s: enlightened vmptrld failed\n", +- __func__); +- vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; +- vcpu->run->internal.suberror = +- KVM_INTERNAL_ERROR_EMULATION; +- vcpu->run->internal.ndata = 0; ++ evmptrld_status == EVMPTRLD_ERROR) + return false; +- } + } + + return true; +@@ -3236,8 +3229,16 @@ static bool nested_get_vmcs12_pages(stru + + static bool vmx_get_nested_state_pages(struct kvm_vcpu *vcpu) + { +- if (!nested_get_evmcs_page(vcpu)) ++ if (!nested_get_evmcs_page(vcpu)) { ++ pr_debug_ratelimited("%s: enlightened vmptrld failed\n", ++ __func__); ++ vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; ++ vcpu->run->internal.suberror = ++ KVM_INTERNAL_ERROR_EMULATION; ++ vcpu->run->internal.ndata = 0; ++ + return false; ++ } + + if (is_guest_mode(vcpu) && !nested_get_vmcs12_pages(vcpu)) + return false; +@@ -4467,7 +4468,15 @@ void nested_vmx_vmexit(struct kvm_vcpu * + /* trying to cancel vmlaunch/vmresume is a bug */ + WARN_ON_ONCE(vmx->nested.nested_run_pending); + +- kvm_clear_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu); ++ if (kvm_check_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu)) { ++ /* ++ * KVM_REQ_GET_NESTED_STATE_PAGES is also used to map ++ * Enlightened VMCS after migration and we still need to ++ * do that when something is forcing L2->L1 exit prior to ++ * the first L2 run. ++ */ ++ (void)nested_get_evmcs_page(vcpu); ++ } + + /* Service the TLB flush request for L2 before switching to L1. */ + if (kvm_check_request(KVM_REQ_TLB_FLUSH_CURRENT, vcpu)) diff --git a/queue-5.11/kvm-x86-emulate-rdpid-only-if-rdtscp-is-supported.patch b/queue-5.11/kvm-x86-emulate-rdpid-only-if-rdtscp-is-supported.patch new file mode 100644 index 00000000000..39eb5874848 --- /dev/null +++ b/queue-5.11/kvm-x86-emulate-rdpid-only-if-rdtscp-is-supported.patch @@ -0,0 +1,42 @@ +From 85d0011264da24be08ae907d7f29983a597ca9b1 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 4 May 2021 10:17:21 -0700 +Subject: KVM: x86: Emulate RDPID only if RDTSCP is supported + +From: Sean Christopherson + +commit 85d0011264da24be08ae907d7f29983a597ca9b1 upstream. + +Do not advertise emulation support for RDPID if RDTSCP is unsupported. +RDPID emulation subtly relies on MSR_TSC_AUX to exist in hardware, as +both vmx_get_msr() and svm_get_msr() will return an error if the MSR is +unsupported, i.e. ctxt->ops->get_msr() will fail and the emulator will +inject a #UD. + +Note, RDPID emulation also relies on RDTSCP being enabled in the guest, +but this is a KVM bug and will eventually be fixed. + +Fixes: fb6d4d340e05 ("KVM: x86: emulate RDPID") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210504171734.1434054-3-seanjc@google.com> +Reviewed-by: Jim Mattson +Reviewed-by: Reiji Watanabe +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/cpuid.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/cpuid.c ++++ b/arch/x86/kvm/cpuid.c +@@ -573,7 +573,8 @@ static int __do_cpuid_func_emulated(stru + case 7: + entry->flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX; + entry->eax = 0; +- entry->ecx = F(RDPID); ++ if (kvm_cpu_cap_has(X86_FEATURE_RDTSCP)) ++ entry->ecx = F(RDPID); + ++array->nent; + default: + break; diff --git a/queue-5.11/kvm-x86-move-rdpid-emulation-intercept-to-its-own-enum.patch b/queue-5.11/kvm-x86-move-rdpid-emulation-intercept-to-its-own-enum.patch new file mode 100644 index 00000000000..eeebaea0050 --- /dev/null +++ b/queue-5.11/kvm-x86-move-rdpid-emulation-intercept-to-its-own-enum.patch @@ -0,0 +1,59 @@ +From 2183de4161b90bd3851ccd3910c87b2c9adfc6ed Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 4 May 2021 10:17:23 -0700 +Subject: KVM: x86: Move RDPID emulation intercept to its own enum + +From: Sean Christopherson + +commit 2183de4161b90bd3851ccd3910c87b2c9adfc6ed upstream. + +Add a dedicated intercept enum for RDPID instead of piggybacking RDTSCP. +Unlike VMX's ENABLE_RDTSCP, RDPID is not bound to SVM's RDTSCP intercept. + +Fixes: fb6d4d340e05 ("KVM: x86: emulate RDPID") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210504171734.1434054-5-seanjc@google.com> +Reviewed-by: Jim Mattson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/emulate.c | 2 +- + arch/x86/kvm/kvm_emulate.h | 1 + + arch/x86/kvm/vmx/vmx.c | 3 ++- + 3 files changed, 4 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/emulate.c ++++ b/arch/x86/kvm/emulate.c +@@ -4502,7 +4502,7 @@ static const struct opcode group8[] = { + * from the register case of group9. + */ + static const struct gprefix pfx_0f_c7_7 = { +- N, N, N, II(DstMem | ModRM | Op3264 | EmulateOnUD, em_rdpid, rdtscp), ++ N, N, N, II(DstMem | ModRM | Op3264 | EmulateOnUD, em_rdpid, rdpid), + }; + + +--- a/arch/x86/kvm/kvm_emulate.h ++++ b/arch/x86/kvm/kvm_emulate.h +@@ -468,6 +468,7 @@ enum x86_intercept { + x86_intercept_clgi, + x86_intercept_skinit, + x86_intercept_rdtscp, ++ x86_intercept_rdpid, + x86_intercept_icebp, + x86_intercept_wbinvd, + x86_intercept_monitor, +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -7346,8 +7346,9 @@ static int vmx_check_intercept(struct kv + /* + * RDPID causes #UD if disabled through secondary execution controls. + * Because it is marked as EmulateOnUD, we need to intercept it here. ++ * Note, RDPID is hidden behind ENABLE_RDTSCP. + */ +- case x86_intercept_rdtscp: ++ case x86_intercept_rdpid: + if (!nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENABLE_RDTSCP)) { + exception->vector = UD_VECTOR; + exception->error_code_valid = false; diff --git a/queue-5.11/series b/queue-5.11/series index a6960141f5d..a1bcb6e1360 100644 --- a/queue-5.11/series +++ b/queue-5.11/series @@ -287,3 +287,14 @@ usb-dwc3-gadget-enable-suspend-events.patch usb-dwc3-gadget-return-success-always-for-kick-transfer-in-ep-queue.patch usb-typec-ucsi-retrieve-all-the-pdos-instead-of-just-the-first-4.patch usb-typec-ucsi-put-fwnode-in-any-case-during-probe.patch +xhci-pci-allow-host-runtime-pm-as-default-for-intel-alder-lake-xhci.patch +xhci-do-not-use-gfp_kernel-in-potentially-atomic-context.patch +xhci-add-reset-resume-quirk-for-amd-xhci-controller.patch +iio-core-fix-ioctl-handlers-removal.patch +iio-gyro-mpu3050-fix-reported-temperature-value.patch +iio-tsl2583-fix-division-by-a-zero-lux_val.patch +cdc-wdm-untangle-a-circular-dependency-between-callback-and-softint.patch +xen-gntdev-fix-gntdev_mmap-error-exit-path.patch +kvm-x86-emulate-rdpid-only-if-rdtscp-is-supported.patch +kvm-x86-move-rdpid-emulation-intercept-to-its-own-enum.patch +kvm-nvmx-always-make-an-attempt-to-map-evmcs-after-migration.patch diff --git a/queue-5.11/xen-gntdev-fix-gntdev_mmap-error-exit-path.patch b/queue-5.11/xen-gntdev-fix-gntdev_mmap-error-exit-path.patch new file mode 100644 index 00000000000..92ad497421c --- /dev/null +++ b/queue-5.11/xen-gntdev-fix-gntdev_mmap-error-exit-path.patch @@ -0,0 +1,48 @@ +From 970655aa9b42461f8394e4457307005bdeee14d9 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 23 Apr 2021 07:40:38 +0200 +Subject: xen/gntdev: fix gntdev_mmap() error exit path +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Juergen Gross + +commit 970655aa9b42461f8394e4457307005bdeee14d9 upstream. + +Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert") +introduced an error in gntdev_mmap(): in case the call of +mmu_interval_notifier_insert_locked() fails the exit path should not +call mmu_interval_notifier_remove(), as this might result in NULL +dereferences. + +One reason for failure is e.g. a signal pending for the running +process. + +Fixes: d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert") +Cc: stable@vger.kernel.org +Reported-by: Marek Marczykowski-Górecki +Tested-by: Marek Marczykowski-Górecki +Signed-off-by: Juergen Gross +Reviewed-by: Luca Fancellu +Link: https://lore.kernel.org/r/20210423054038.26696-1-jgross@suse.com +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman +--- + drivers/xen/gntdev.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/xen/gntdev.c ++++ b/drivers/xen/gntdev.c +@@ -1005,8 +1005,10 @@ static int gntdev_mmap(struct file *flip + err = mmu_interval_notifier_insert_locked( + &map->notifier, vma->vm_mm, vma->vm_start, + vma->vm_end - vma->vm_start, &gntdev_mmu_ops); +- if (err) ++ if (err) { ++ map->vma = NULL; + goto out_unlock_put; ++ } + } + mutex_unlock(&priv->lock); + diff --git a/queue-5.11/xhci-add-reset-resume-quirk-for-amd-xhci-controller.patch b/queue-5.11/xhci-add-reset-resume-quirk-for-amd-xhci-controller.patch new file mode 100644 index 00000000000..db0382f940c --- /dev/null +++ b/queue-5.11/xhci-add-reset-resume-quirk-for-amd-xhci-controller.patch @@ -0,0 +1,38 @@ +From 3c128781d8da463761495aaf8898c9ecb4e71528 Mon Sep 17 00:00:00 2001 +From: Sandeep Singh +Date: Wed, 12 May 2021 11:08:16 +0300 +Subject: xhci: Add reset resume quirk for AMD xhci controller. + +From: Sandeep Singh + +commit 3c128781d8da463761495aaf8898c9ecb4e71528 upstream. + +One of AMD xhci controller require reset on resume. +Occasionally AMD xhci controller does not respond to +Stop endpoint command. +Once the issue happens controller goes into bad state +and in that case controller needs to be reset. + +Cc: +Signed-off-by: Sandeep Singh +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -167,8 +167,10 @@ static void xhci_pci_quirks(struct devic + (pdev->device == 0x15e0 || pdev->device == 0x15e1)) + xhci->quirks |= XHCI_SNPS_BROKEN_SUSPEND; + +- if (pdev->vendor == PCI_VENDOR_ID_AMD && pdev->device == 0x15e5) ++ if (pdev->vendor == PCI_VENDOR_ID_AMD && pdev->device == 0x15e5) { + xhci->quirks |= XHCI_DISABLE_SPARSE; ++ xhci->quirks |= XHCI_RESET_ON_RESUME; ++ } + + if (pdev->vendor == PCI_VENDOR_ID_AMD) + xhci->quirks |= XHCI_TRUST_TX_LENGTH; diff --git a/queue-5.11/xhci-do-not-use-gfp_kernel-in-potentially-atomic-context.patch b/queue-5.11/xhci-do-not-use-gfp_kernel-in-potentially-atomic-context.patch new file mode 100644 index 00000000000..2bfd2807919 --- /dev/null +++ b/queue-5.11/xhci-do-not-use-gfp_kernel-in-potentially-atomic-context.patch @@ -0,0 +1,58 @@ +From dda32c00c9a0fa103b5d54ef72c477b7aa993679 Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Wed, 12 May 2021 11:08:14 +0300 +Subject: xhci: Do not use GFP_KERNEL in (potentially) atomic context + +From: Christophe JAILLET + +commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream. + +'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be +submitted in interrupt context" (see comment related to 'usb_submit_urb()' +in 'drivers/usb/core/urb.c') + +So this flag should be used in all the calling chain. +Up to now, 'xhci_check_maxpacket()' which is only called from +'xhci_urb_enqueue()', uses GFP_KERNEL. + +Be safe and pass the mem_flags to this function as well. + +Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring") +Cc: +Signed-off-by: Christophe JAILLET +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -1523,7 +1523,7 @@ static int xhci_configure_endpoint(struc + * we need to issue an evaluate context command and wait on it. + */ + static int xhci_check_maxpacket(struct xhci_hcd *xhci, unsigned int slot_id, +- unsigned int ep_index, struct urb *urb) ++ unsigned int ep_index, struct urb *urb, gfp_t mem_flags) + { + struct xhci_container_ctx *out_ctx; + struct xhci_input_control_ctx *ctrl_ctx; +@@ -1554,7 +1554,7 @@ static int xhci_check_maxpacket(struct x + * changes max packet sizes. + */ + +- command = xhci_alloc_command(xhci, true, GFP_KERNEL); ++ command = xhci_alloc_command(xhci, true, mem_flags); + if (!command) + return -ENOMEM; + +@@ -1648,7 +1648,7 @@ static int xhci_urb_enqueue(struct usb_h + */ + if (urb->dev->speed == USB_SPEED_FULL) { + ret = xhci_check_maxpacket(xhci, slot_id, +- ep_index, urb); ++ ep_index, urb, mem_flags); + if (ret < 0) { + xhci_urb_free_priv(urb_priv); + urb->hcpriv = NULL; diff --git a/queue-5.11/xhci-pci-allow-host-runtime-pm-as-default-for-intel-alder-lake-xhci.patch b/queue-5.11/xhci-pci-allow-host-runtime-pm-as-default-for-intel-alder-lake-xhci.patch new file mode 100644 index 00000000000..b8727c153f3 --- /dev/null +++ b/queue-5.11/xhci-pci-allow-host-runtime-pm-as-default-for-intel-alder-lake-xhci.patch @@ -0,0 +1,44 @@ +From b813511135e8b84fa741afdfbab4937919100bef Mon Sep 17 00:00:00 2001 +From: Abhijeet Rao +Date: Wed, 12 May 2021 11:08:12 +0300 +Subject: xhci-pci: Allow host runtime PM as default for Intel Alder Lake xHCI + +From: Abhijeet Rao + +commit b813511135e8b84fa741afdfbab4937919100bef upstream. + +In the same way as Intel Tiger Lake TCSS (Type-C Subsystem) the Alder Lake +TCSS xHCI needs to be runtime suspended whenever possible to allow the +TCSS hardware block to enter D3cold and thus save energy. + +Cc: stable@vger.kernel.org +Signed-off-by: Abhijeet Rao +Signed-off-by: Nikunj A. Dadhania +Signed-off-by: Azhar Shaikh +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20210512080816.866037-2-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -57,6 +57,7 @@ + #define PCI_DEVICE_ID_INTEL_CML_XHCI 0xa3af + #define PCI_DEVICE_ID_INTEL_TIGER_LAKE_XHCI 0x9a13 + #define PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_XHCI 0x1138 ++#define PCI_DEVICE_ID_INTEL_ALDER_LAKE_XHCI 0x461e + + #define PCI_DEVICE_ID_AMD_PROMONTORYA_4 0x43b9 + #define PCI_DEVICE_ID_AMD_PROMONTORYA_3 0x43ba +@@ -243,7 +244,8 @@ static void xhci_pci_quirks(struct devic + pdev->device == PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_ICE_LAKE_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_TIGER_LAKE_XHCI || +- pdev->device == PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_XHCI)) ++ pdev->device == PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_XHCI || ++ pdev->device == PCI_DEVICE_ID_INTEL_ALDER_LAKE_XHCI)) + xhci->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW; + + if (pdev->vendor == PCI_VENDOR_ID_ETRON &&