--- /dev/null
+From f3a8076eb28cae1553958c629aecec479394bbe2 Mon Sep 17 00:00:00 2001
+From: Le Ma <le.ma@amd.com>
+Date: Sat, 4 Dec 2021 18:59:08 +0800
+Subject: drm/amdgpu: correct register access for RLC_JUMP_TABLE_RESTORE
+
+From: Le Ma <le.ma@amd.com>
+
+commit f3a8076eb28cae1553958c629aecec479394bbe2 upstream.
+
+should count on GC IP base address
+
+Signed-off-by: Le Ma <le.ma@amd.com>
+Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+ }
--- /dev/null
+From 5da5231bb47864e5dd6c6731151e98b6ee498827 Mon Sep 17 00:00:00 2001
+From: George Kennedy <george.kennedy@oracle.com>
+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 <george.kennedy@oracle.com>
+
+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: <stable@vger.kernel.org>
+Reported-by: syzkaller<syzkaller@googlegroups.com>
+Signed-off-by: George Kennedy<george.kennedy@oracle.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 94185adbfad56815c2c8401e16d81bdb74a79201 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 14 Dec 2021 12:42:14 +0100
+Subject: PCI/MSI: Clear PCI_MSIX_FLAGS_MASKALL on error
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <sr@denx.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Stefan Roese <sr@denx.de>
+Cc: linux-pci@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Michal Simek <michal.simek@xilinx.com>
+Cc: Marek Vasut <marex@denx.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 83dbf898a2d45289be875deb580e93050ba67529 Mon Sep 17 00:00:00 2001
+From: Stefan Roese <sr@denx.de>
+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 <sr@denx.de>
+
+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 <sr@denx.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-pci@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Michal Simek <michal.simek@xilinx.com>
+Cc: Marek Vasut <marex@denx.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
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
--- /dev/null
+From 4e8c11b6b3f0b6a283e898344f154641eda94266 Mon Sep 17 00:00:00 2001
+From: Yu Liao <liaoyu15@huawei.com>
+Date: Mon, 13 Dec 2021 21:57:27 +0800
+Subject: timekeeping: Really make sure wall_to_monotonic isn't positive
+
+From: Yu Liao <liaoyu15@huawei.com>
+
+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 <liaoyu15@huawei.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20211213135727.1656662-1-liaoyu15@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 0ad3bd562bb91853b9f42bda145b5db6255aee90 Mon Sep 17 00:00:00 2001
+From: Jimmy Wang <wangjm221@gmail.com>
+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 <wangjm221@gmail.com>
+
+commit 0ad3bd562bb91853b9f42bda145b5db6255aee90 upstream.
+
+This device doesn't work well with LPM, losing connectivity intermittently.
+Disable LPM to resolve the issue.
+
+Reviewed-by: <markpearson@lenovo.com>
+Signed-off-by: Jimmy Wang <wangjm221@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 },
+
--- /dev/null
+From 83b67041f3eaf33f98a075249aa7f4c7617c2f85 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 26 Nov 2021 10:43:48 +0100
+Subject: USB: serial: cp210x: fix CP2105 GPIO registration
+
+From: Johan Hovold <johan@kernel.org>
+
+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 <m.brock@vanmierlo.com>
+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 <pados@pados.hu>
+Link: https://lore.kernel.org/r/20211126094348.31698-1-johan@kernel.org
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Tested-by: Maarten Brock <m.brock@vanmierlo.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 2b503c8598d1b232e7fc7526bce9326d92331541 Mon Sep 17 00:00:00 2001
+From: Daniele Palmas <dnlplm@gmail.com>
+Date: Fri, 10 Dec 2021 11:07:14 +0100
+Subject: USB: serial: option: add Telit FN990 compositions
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+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 <dnlplm@gmail.com>
+Link: https://lore.kernel.org/r/20211210100714.22587-1-dnlplm@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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),
--- /dev/null
+From f886d4fbb7c97b8f5f447c92d2dab99c841803c0 Mon Sep 17 00:00:00 2001
+From: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>
+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 <Nehal-Bakulchandra.shah@amd.com>
+
+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 <Nehal-Bakulchandra.shah@amd.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211215093216.1839065-1-Nehal-Bakulchandra.shah@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
projects / thirdparty / kernel / stable-queue.git / commitdiff
