From: Greg Kroah-Hartman Date: Mon, 20 Dec 2021 09:44:22 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.296~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5ebe0fdc67ac0e3d860256a5f65ffdbf73a62db4;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch pci-msi-clear-pci_msix_flags_maskall-on-error.patch pci-msi-mask-msi-x-vectors-only-on-success.patch timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch usb-serial-cp210x-fix-cp2105-gpio-registration.patch usb-serial-option-add-telit-fn990-compositions.patch usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch --- diff --git a/queue-5.4/drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch b/queue-5.4/drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch new file mode 100644 index 00000000000..0b4b88fad3f --- /dev/null +++ b/queue-5.4/drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch @@ -0,0 +1,34 @@ +From f3a8076eb28cae1553958c629aecec479394bbe2 Mon Sep 17 00:00:00 2001 +From: Le Ma +Date: Sat, 4 Dec 2021 18:59:08 +0800 +Subject: drm/amdgpu: correct register access for RLC_JUMP_TABLE_RESTORE + +From: Le Ma + +commit f3a8076eb28cae1553958c629aecec479394bbe2 upstream. + +should count on GC IP base address + +Signed-off-by: Le Ma +Signed-off-by: Hawking Zhang +Reviewed-by: Hawking Zhang +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +@@ -2906,8 +2906,8 @@ static void gfx_v9_0_init_pg(struct amdg + AMD_PG_SUPPORT_CP | + AMD_PG_SUPPORT_GDS | + AMD_PG_SUPPORT_RLC_SMU_HS)) { +- WREG32(mmRLC_JUMP_TABLE_RESTORE, +- adev->gfx.rlc.cp_table_gpu_addr >> 8); ++ WREG32_SOC15(GC, 0, mmRLC_JUMP_TABLE_RESTORE, ++ adev->gfx.rlc.cp_table_gpu_addr >> 8); + gfx_v9_0_init_gfx_power_gating(adev); + } + } diff --git a/queue-5.4/libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch b/queue-5.4/libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch new file mode 100644 index 00000000000..332c0223b8a --- /dev/null +++ b/queue-5.4/libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch @@ -0,0 +1,46 @@ +From 5da5231bb47864e5dd6c6731151e98b6ee498827 Mon Sep 17 00:00:00 2001 +From: George Kennedy +Date: Tue, 14 Dec 2021 09:45:10 -0500 +Subject: libata: if T_LENGTH is zero, dma direction should be DMA_NONE + +From: George Kennedy + +commit 5da5231bb47864e5dd6c6731151e98b6ee498827 upstream. + +Avoid data corruption by rejecting pass-through commands where +T_LENGTH is zero (No data is transferred) and the dma direction +is not DMA_NONE. + +Cc: +Reported-by: syzkaller +Signed-off-by: George Kennedy +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/libata-scsi.c | 15 +++++++++++++-- + 1 file changed, 13 insertions(+), 2 deletions(-) + +--- a/drivers/ata/libata-scsi.c ++++ b/drivers/ata/libata-scsi.c +@@ -3164,8 +3164,19 @@ static unsigned int ata_scsi_pass_thru(s + goto invalid_fld; + } + +- if (ata_is_ncq(tf->protocol) && (cdb[2 + cdb_offset] & 0x3) == 0) +- tf->protocol = ATA_PROT_NCQ_NODATA; ++ if ((cdb[2 + cdb_offset] & 0x3) == 0) { ++ /* ++ * When T_LENGTH is zero (No data is transferred), dir should ++ * be DMA_NONE. ++ */ ++ if (scmd->sc_data_direction != DMA_NONE) { ++ fp = 2 + cdb_offset; ++ goto invalid_fld; ++ } ++ ++ if (ata_is_ncq(tf->protocol)) ++ tf->protocol = ATA_PROT_NCQ_NODATA; ++ } + + /* enable LBA */ + tf->flags |= ATA_TFLAG_LBA; diff --git a/queue-5.4/pci-msi-clear-pci_msix_flags_maskall-on-error.patch b/queue-5.4/pci-msi-clear-pci_msix_flags_maskall-on-error.patch new file mode 100644 index 00000000000..b27ed24b076 --- /dev/null +++ b/queue-5.4/pci-msi-clear-pci_msix_flags_maskall-on-error.patch @@ -0,0 +1,46 @@ +From 94185adbfad56815c2c8401e16d81bdb74a79201 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 14 Dec 2021 12:42:14 +0100 +Subject: PCI/MSI: Clear PCI_MSIX_FLAGS_MASKALL on error + +From: Thomas Gleixner + +commit 94185adbfad56815c2c8401e16d81bdb74a79201 upstream. + +PCI_MSIX_FLAGS_MASKALL is set in the MSI-X control register at MSI-X +interrupt setup time. It's cleared on success, but the error handling path +only clears the PCI_MSIX_FLAGS_ENABLE bit. + +That's incorrect as the reset state of the PCI_MSIX_FLAGS_MASKALL bit is +zero. That can be observed via lspci: + + Capabilities: [b0] MSI-X: Enable- Count=67 Masked+ + +Clear the bit in the error path to restore the reset state. + +Fixes: 438553958ba1 ("PCI/MSI: Enable and mask MSI-X early") +Reported-by: Stefan Roese +Signed-off-by: Thomas Gleixner +Tested-by: Stefan Roese +Cc: linux-pci@vger.kernel.org +Cc: Bjorn Helgaas +Cc: Michal Simek +Cc: Marek Vasut +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/msi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pci/msi.c ++++ b/drivers/pci/msi.c +@@ -878,7 +878,7 @@ out_free: + free_msi_irqs(dev); + + out_disable: +- pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0); ++ pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL | PCI_MSIX_FLAGS_ENABLE, 0); + + return ret; + } diff --git a/queue-5.4/pci-msi-mask-msi-x-vectors-only-on-success.patch b/queue-5.4/pci-msi-mask-msi-x-vectors-only-on-success.patch new file mode 100644 index 00000000000..51a976b4159 --- /dev/null +++ b/queue-5.4/pci-msi-mask-msi-x-vectors-only-on-success.patch @@ -0,0 +1,77 @@ +From 83dbf898a2d45289be875deb580e93050ba67529 Mon Sep 17 00:00:00 2001 +From: Stefan Roese +Date: Tue, 14 Dec 2021 12:49:32 +0100 +Subject: PCI/MSI: Mask MSI-X vectors only on success +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Stefan Roese + +commit 83dbf898a2d45289be875deb580e93050ba67529 upstream. + +Masking all unused MSI-X entries is done to ensure that a crash kernel +starts from a clean slate, which correponds to the reset state of the +device as defined in the PCI-E specificion 3.0 and later: + + Vector Control for MSI-X Table Entries + -------------------------------------- + + "00: Mask bit: When this bit is set, the function is prohibited from + sending a message using this MSI-X Table entry. + ... + This bit’s state after reset is 1 (entry is masked)." + +A Marvell NVME device fails to deliver MSI interrupts after trying to +enable MSI-X interrupts due to that masking. It seems to take the MSI-X +mask bits into account even when MSI-X is disabled. + +While not specification compliant, this can be cured by moving the masking +into the success path, so that the MSI-X table entries stay in device reset +state when the MSI-X setup fails. + +[ tglx: Move it into the success path, add comment and amend changelog ] + +Fixes: aa8092c1d1f1 ("PCI/MSI: Mask all unused MSI-X entries") +Signed-off-by: Stefan Roese +Signed-off-by: Thomas Gleixner +Cc: linux-pci@vger.kernel.org +Cc: Bjorn Helgaas +Cc: Michal Simek +Cc: Marek Vasut +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/msi.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/pci/msi.c ++++ b/drivers/pci/msi.c +@@ -827,9 +827,6 @@ static int msix_capability_init(struct p + goto out_disable; + } + +- /* Ensure that all table entries are masked. */ +- msix_mask_all(base, tsize); +- + ret = msix_setup_entries(dev, base, entries, nvec, affd); + if (ret) + goto out_disable; +@@ -852,6 +849,16 @@ static int msix_capability_init(struct p + /* Set MSI-X enabled bits and unmask the function */ + pci_intx_for_msi(dev, 0); + dev->msix_enabled = 1; ++ ++ /* ++ * Ensure that all table entries are masked to prevent ++ * stale entries from firing in a crash kernel. ++ * ++ * Done late to deal with a broken Marvell NVME device ++ * which takes the MSI-X mask bits into account even ++ * when MSI-X is disabled, which prevents MSI delivery. ++ */ ++ msix_mask_all(base, tsize); + pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0); + + pcibios_free_irq(dev); diff --git a/queue-5.4/series b/queue-5.4/series index 386f137ce23..2ba378e8e10 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -42,3 +42,12 @@ net-smc-prevent-smc_release-from-long-blocking.patch net-systemport-add-global-locking-for-descriptor-lif.patch sit-do-not-call-ipip6_dev_free-from-sit_init_net.patch usb-gadget-brequesttype-is-a-bitfield-not-a-enum.patch +usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch +pci-msi-clear-pci_msix_flags_maskall-on-error.patch +pci-msi-mask-msi-x-vectors-only-on-success.patch +usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch +usb-serial-cp210x-fix-cp2105-gpio-registration.patch +usb-serial-option-add-telit-fn990-compositions.patch +timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch +libata-if-t_length-is-zero-dma-direction-should-be-dma_none.patch +drm-amdgpu-correct-register-access-for-rlc_jump_table_restore.patch diff --git a/queue-5.4/timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch b/queue-5.4/timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch new file mode 100644 index 00000000000..105b3743034 --- /dev/null +++ b/queue-5.4/timekeeping-really-make-sure-wall_to_monotonic-isn-t-positive.patch @@ -0,0 +1,65 @@ +From 4e8c11b6b3f0b6a283e898344f154641eda94266 Mon Sep 17 00:00:00 2001 +From: Yu Liao +Date: Mon, 13 Dec 2021 21:57:27 +0800 +Subject: timekeeping: Really make sure wall_to_monotonic isn't positive + +From: Yu Liao + +commit 4e8c11b6b3f0b6a283e898344f154641eda94266 upstream. + +Even after commit e1d7ba873555 ("time: Always make sure wall_to_monotonic +isn't positive") it is still possible to make wall_to_monotonic positive +by running the following code: + + int main(void) + { + struct timespec time; + + clock_gettime(CLOCK_MONOTONIC, &time); + time.tv_nsec = 0; + clock_settime(CLOCK_REALTIME, &time); + return 0; + } + +The reason is that the second parameter of timespec64_compare(), ts_delta, +may be unnormalized because the delta is calculated with an open coded +substraction which causes the comparison of tv_sec to yield the wrong +result: + + wall_to_monotonic = { .tv_sec = -10, .tv_nsec = 900000000 } + ts_delta = { .tv_sec = -9, .tv_nsec = -900000000 } + +That makes timespec64_compare() claim that wall_to_monotonic < ts_delta, +but actually the result should be wall_to_monotonic > ts_delta. + +After normalization, the result of timespec64_compare() is correct because +the tv_sec comparison is not longer misleading: + + wall_to_monotonic = { .tv_sec = -10, .tv_nsec = 900000000 } + ts_delta = { .tv_sec = -10, .tv_nsec = 100000000 } + +Use timespec64_sub() to ensure that ts_delta is normalized, which fixes the +issue. + +Fixes: e1d7ba873555 ("time: Always make sure wall_to_monotonic isn't positive") +Signed-off-by: Yu Liao +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20211213135727.1656662-1-liaoyu15@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/timekeeping.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/time/timekeeping.c ++++ b/kernel/time/timekeeping.c +@@ -1236,8 +1236,7 @@ int do_settimeofday64(const struct times + timekeeping_forward_now(tk); + + xt = tk_xtime(tk); +- ts_delta.tv_sec = ts->tv_sec - xt.tv_sec; +- ts_delta.tv_nsec = ts->tv_nsec - xt.tv_nsec; ++ ts_delta = timespec64_sub(*ts, xt); + + if (timespec64_compare(&tk->wall_to_monotonic, &ts_delta) > 0) { + ret = -EINVAL; diff --git a/queue-5.4/usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch b/queue-5.4/usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch new file mode 100644 index 00000000000..26a8002c9d3 --- /dev/null +++ b/queue-5.4/usb-no_lpm-quirk-lenovo-usb-c-to-ethernet-adapher-rtl8153-04.patch @@ -0,0 +1,33 @@ +From 0ad3bd562bb91853b9f42bda145b5db6255aee90 Mon Sep 17 00:00:00 2001 +From: Jimmy Wang +Date: Tue, 14 Dec 2021 09:26:50 +0800 +Subject: USB: NO_LPM quirk Lenovo USB-C to Ethernet Adapher(RTL8153-04) + +From: Jimmy Wang + +commit 0ad3bd562bb91853b9f42bda145b5db6255aee90 upstream. + +This device doesn't work well with LPM, losing connectivity intermittently. +Disable LPM to resolve the issue. + +Reviewed-by: +Signed-off-by: Jimmy Wang +Cc: stable +Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/quirks.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -435,6 +435,9 @@ static const struct usb_device_id usb_qu + { USB_DEVICE(0x1532, 0x0116), .driver_info = + USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL }, + ++ /* Lenovo USB-C to Ethernet Adapter RTL8153-04 */ ++ { USB_DEVICE(0x17ef, 0x720c), .driver_info = USB_QUIRK_NO_LPM }, ++ + /* Lenovo Powered USB-C Travel Hub (4X90S92381, RTL8153 GigE) */ + { USB_DEVICE(0x17ef, 0x721e), .driver_info = USB_QUIRK_NO_LPM }, + diff --git a/queue-5.4/usb-serial-cp210x-fix-cp2105-gpio-registration.patch b/queue-5.4/usb-serial-cp210x-fix-cp2105-gpio-registration.patch new file mode 100644 index 00000000000..b59072b9adc --- /dev/null +++ b/queue-5.4/usb-serial-cp210x-fix-cp2105-gpio-registration.patch @@ -0,0 +1,68 @@ +From 83b67041f3eaf33f98a075249aa7f4c7617c2f85 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 26 Nov 2021 10:43:48 +0100 +Subject: USB: serial: cp210x: fix CP2105 GPIO registration + +From: Johan Hovold + +commit 83b67041f3eaf33f98a075249aa7f4c7617c2f85 upstream. + +When generalising GPIO support and adding support for CP2102N, the GPIO +registration for some CP2105 devices accidentally broke. Specifically, +when all the pins of a port are in "modem" mode, and thus unavailable +for GPIO use, the GPIO chip would now be registered without having +initialised the number of GPIO lines. This would in turn be rejected by +gpiolib and some errors messages would be printed (but importantly probe +would still succeed). + +Fix this by initialising the number of GPIO lines before registering the +GPIO chip. + +Note that as for the other device types, and as when all CP2105 pins are +muxed for LED function, the GPIO chip is registered also when no pins +are available for GPIO use. + +Reported-by: Maarten Brock +Link: https://lore.kernel.org/r/5eb560c81d2ea1a2b4602a92d9f48a89@vanmierlo.com +Fixes: c8acfe0aadbe ("USB: serial: cp210x: implement GPIO support for CP2102N") +Cc: stable@vger.kernel.org # 4.19 +Cc: Karoly Pados +Link: https://lore.kernel.org/r/20211126094348.31698-1-johan@kernel.org +Reviewed-by: Greg Kroah-Hartman +Tested-by: Maarten Brock +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/cp210x.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/usb/serial/cp210x.c ++++ b/drivers/usb/serial/cp210x.c +@@ -1552,6 +1552,8 @@ static int cp2105_gpioconf_init(struct u + + /* 2 banks of GPIO - One for the pins taken from each serial port */ + if (intf_num == 0) { ++ priv->gc.ngpio = 2; ++ + if (mode.eci == CP210X_PIN_MODE_MODEM) { + /* mark all GPIOs of this interface as reserved */ + priv->gpio_altfunc = 0xff; +@@ -1562,8 +1564,9 @@ static int cp2105_gpioconf_init(struct u + priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) & + CP210X_ECI_GPIO_MODE_MASK) >> + CP210X_ECI_GPIO_MODE_OFFSET); +- priv->gc.ngpio = 2; + } else if (intf_num == 1) { ++ priv->gc.ngpio = 3; ++ + if (mode.sci == CP210X_PIN_MODE_MODEM) { + /* mark all GPIOs of this interface as reserved */ + priv->gpio_altfunc = 0xff; +@@ -1574,7 +1577,6 @@ static int cp2105_gpioconf_init(struct u + priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) & + CP210X_SCI_GPIO_MODE_MASK) >> + CP210X_SCI_GPIO_MODE_OFFSET); +- priv->gc.ngpio = 3; + } else { + return -ENODEV; + } diff --git a/queue-5.4/usb-serial-option-add-telit-fn990-compositions.patch b/queue-5.4/usb-serial-option-add-telit-fn990-compositions.patch new file mode 100644 index 00000000000..1b6302d3fd4 --- /dev/null +++ b/queue-5.4/usb-serial-option-add-telit-fn990-compositions.patch @@ -0,0 +1,42 @@ +From 2b503c8598d1b232e7fc7526bce9326d92331541 Mon Sep 17 00:00:00 2001 +From: Daniele Palmas +Date: Fri, 10 Dec 2021 11:07:14 +0100 +Subject: USB: serial: option: add Telit FN990 compositions + +From: Daniele Palmas + +commit 2b503c8598d1b232e7fc7526bce9326d92331541 upstream. + +Add the following Telit FN990 compositions: + +0x1070: tty, adb, rmnet, tty, tty, tty, tty +0x1071: tty, adb, mbim, tty, tty, tty, tty +0x1072: rndis, tty, adb, tty, tty, tty, tty +0x1073: tty, adb, ecm, tty, tty, tty, tty + +Signed-off-by: Daniele Palmas +Link: https://lore.kernel.org/r/20211210100714.22587-1-dnlplm@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/option.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/usb/serial/option.c ++++ b/drivers/usb/serial/option.c +@@ -1219,6 +1219,14 @@ static const struct usb_device_id option + .driver_info = NCTRL(2) | RSVD(3) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1063, 0xff), /* Telit LN920 (ECM) */ + .driver_info = NCTRL(0) | RSVD(1) }, ++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1070, 0xff), /* Telit FN990 (rmnet) */ ++ .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) }, ++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1071, 0xff), /* Telit FN990 (MBIM) */ ++ .driver_info = NCTRL(0) | RSVD(1) }, ++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1072, 0xff), /* Telit FN990 (RNDIS) */ ++ .driver_info = NCTRL(2) | RSVD(3) }, ++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1073, 0xff), /* Telit FN990 (ECM) */ ++ .driver_info = NCTRL(0) | RSVD(1) }, + { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910), + .driver_info = NCTRL(0) | RSVD(1) | RSVD(3) }, + { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM), diff --git a/queue-5.4/usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch b/queue-5.4/usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch new file mode 100644 index 00000000000..6478bdca6df --- /dev/null +++ b/queue-5.4/usb-xhci-extend-support-for-runtime-power-management-for-amd-s-yellow-carp.patch @@ -0,0 +1,42 @@ +From f886d4fbb7c97b8f5f447c92d2dab99c841803c0 Mon Sep 17 00:00:00 2001 +From: Nehal Bakulchandra Shah +Date: Wed, 15 Dec 2021 15:02:16 +0530 +Subject: usb: xhci: Extend support for runtime power management for AMD's Yellow carp. + +From: Nehal Bakulchandra Shah + +commit f886d4fbb7c97b8f5f447c92d2dab99c841803c0 upstream. + +AMD's Yellow Carp platform has few more XHCI controllers, +enable the runtime power management support for the same. + +Signed-off-by: Nehal Bakulchandra Shah +Cc: stable +Link: https://lore.kernel.org/r/20211215093216.1839065-1-Nehal-Bakulchandra.shah@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -65,6 +65,8 @@ + #define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_4 0x161e + #define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_5 0x15d6 + #define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_6 0x15d7 ++#define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_7 0x161c ++#define PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_8 0x161f + + #define PCI_DEVICE_ID_ASMEDIA_1042_XHCI 0x1042 + #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142 +@@ -303,7 +305,9 @@ static void xhci_pci_quirks(struct devic + pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_3 || + pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_4 || + pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_5 || +- pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_6)) ++ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_6 || ++ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_7 || ++ pdev->device == PCI_DEVICE_ID_AMD_YELLOW_CARP_XHCI_8)) + xhci->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW; + + if (xhci->quirks & XHCI_RESET_ON_RESUME)