--- /dev/null
+From d683469b3c93d7e2afd39e6e1970f24700eb7a68 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 9 Mar 2020 10:59:22 +0100
+Subject: ALSA: line6: Fix endless MIDI read loop
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit d683469b3c93d7e2afd39e6e1970f24700eb7a68 upstream.
+
+The MIDI input event parser of the LINE6 driver may enter into an
+endless loop when the unexpected data sequence is given, as it tries
+to continue the secondary bytes without termination. Also, when the
+input data is too short, the parser returns a negative error, while
+the caller doesn't handle it properly. This would lead to the
+unexpected behavior as well.
+
+This patch addresses those issues by checking the return value
+correctly and handling the one-byte event in the parser properly.
+
+The bug was reported by syzkaller.
+
+Reported-by: syzbot+cce32521ee0a824c21f7@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/000000000000033087059f8f8fa3@google.com
+Link: https://lore.kernel.org/r/20200309095922.30269-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/line6/driver.c | 2 +-
+ sound/usb/line6/midibuf.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/line6/driver.c
++++ b/sound/usb/line6/driver.c
+@@ -320,7 +320,7 @@ static void line6_data_received(struct u
+ line6_midibuf_read(mb, line6->buffer_message,
+ LINE6_MIDI_MESSAGE_MAXLEN);
+
+- if (done == 0)
++ if (done <= 0)
+ break;
+
+ line6->message_length = done;
+--- a/sound/usb/line6/midibuf.c
++++ b/sound/usb/line6/midibuf.c
+@@ -163,7 +163,7 @@ int line6_midibuf_read(struct midi_buffe
+ int midi_length_prev =
+ midibuf_message_length(this->command_prev);
+
+- if (midi_length_prev > 0) {
++ if (midi_length_prev > 1) {
+ midi_length = midi_length_prev - 1;
+ repeat = 1;
+ } else
--- /dev/null
+From f2ecf903ef06eb1bbbfa969db9889643d487e73a Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 9 Mar 2020 09:21:48 +0100
+Subject: ALSA: pcm: oss: Avoid plugin buffer overflow
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit f2ecf903ef06eb1bbbfa969db9889643d487e73a upstream.
+
+Each OSS PCM plugins allocate its internal buffer per pre-calculation
+of the max buffer size through the chain of plugins (calling
+src_frames and dst_frames callbacks). This works for most plugins,
+but the rate plugin might behave incorrectly. The calculation in the
+rate plugin involves with the fractional position, i.e. it may vary
+depending on the input position. Since the buffer size
+pre-calculation is always done with the offset zero, it may return a
+shorter size than it might be; this may result in the out-of-bound
+access as spotted by fuzzer.
+
+This patch addresses those possible buffer overflow accesses by simply
+setting the upper limit per the given buffer size for each plugin
+before src_frames() and after dst_frames() calls.
+
+Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com
+Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/oss/pcm_plugin.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/sound/core/oss/pcm_plugin.c
++++ b/sound/core/oss/pcm_plugin.c
+@@ -209,6 +209,8 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ plugin = snd_pcm_plug_last(plug);
+ while (plugin && drv_frames > 0) {
++ if (drv_frames > plugin->buf_frames)
++ drv_frames = plugin->buf_frames;
+ plugin_prev = plugin->prev;
+ if (plugin->src_frames)
+ drv_frames = plugin->src_frames(plugin, drv_frames);
+@@ -220,6 +222,8 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ plugin_next = plugin->next;
+ if (plugin->dst_frames)
+ drv_frames = plugin->dst_frames(plugin, drv_frames);
++ if (drv_frames > plugin->buf_frames)
++ drv_frames = plugin->buf_frames;
+ plugin = plugin_next;
+ }
+ } else
+@@ -248,11 +252,15 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
+ if (frames < 0)
+ return frames;
+ }
++ if (frames > plugin->buf_frames)
++ frames = plugin->buf_frames;
+ plugin = plugin_next;
+ }
+ } else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
+ plugin = snd_pcm_plug_last(plug);
+ while (plugin) {
++ if (frames > plugin->buf_frames)
++ frames = plugin->buf_frames;
+ plugin_prev = plugin->prev;
+ if (plugin->src_frames) {
+ frames = plugin->src_frames(plugin, frames);
--- /dev/null
+From 5461e0530c222129dfc941058be114b5cbc00837 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 12 Mar 2020 16:57:30 +0100
+Subject: ALSA: pcm: oss: Remove WARNING from snd_pcm_plug_alloc() checks
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 5461e0530c222129dfc941058be114b5cbc00837 upstream.
+
+The return value checks in snd_pcm_plug_alloc() are covered with
+snd_BUG_ON() macro that may trigger a kernel WARNING depending on the
+kconfig. But since the error condition can be triggered by a weird
+user space parameter passed to OSS layer, we shouldn't give the kernel
+stack trace just for that. As it's a normal error condition, let's
+remove snd_BUG_ON() macro usage there.
+
+Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/oss/pcm_plugin.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/core/oss/pcm_plugin.c
++++ b/sound/core/oss/pcm_plugin.c
+@@ -111,7 +111,7 @@ int snd_pcm_plug_alloc(struct snd_pcm_su
+ while (plugin->next) {
+ if (plugin->dst_frames)
+ frames = plugin->dst_frames(plugin, frames);
+- if (snd_BUG_ON((snd_pcm_sframes_t)frames <= 0))
++ if ((snd_pcm_sframes_t)frames <= 0)
+ return -ENXIO;
+ plugin = plugin->next;
+ err = snd_pcm_plugin_alloc(plugin, frames);
+@@ -123,7 +123,7 @@ int snd_pcm_plug_alloc(struct snd_pcm_su
+ while (plugin->prev) {
+ if (plugin->src_frames)
+ frames = plugin->src_frames(plugin, frames);
+- if (snd_BUG_ON((snd_pcm_sframes_t)frames <= 0))
++ if ((snd_pcm_sframes_t)frames <= 0)
+ return -ENXIO;
+ plugin = plugin->prev;
+ err = snd_pcm_plugin_alloc(plugin, frames);
--- /dev/null
+From 6c3171ef76a0bad892050f6959a7eac02fb16df7 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 16 Mar 2020 10:05:06 +0100
+Subject: ALSA: seq: oss: Fix running status after receiving sysex
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 6c3171ef76a0bad892050f6959a7eac02fb16df7 upstream.
+
+This is a similar bug like the previous case for virmidi: the invalid
+running status is kept after receiving a sysex message.
+
+Again the fix is to clear the running status after handling the sysex.
+
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
+Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/seq/oss/seq_oss_midi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/core/seq/oss/seq_oss_midi.c
++++ b/sound/core/seq/oss/seq_oss_midi.c
+@@ -615,6 +615,7 @@ send_midi_event(struct seq_oss_devinfo *
+ len = snd_seq_oss_timer_start(dp->timer);
+ if (ev->type == SNDRV_SEQ_EVENT_SYSEX) {
+ snd_seq_oss_readq_sysex(dp->readq, mdev->seq_device, ev);
++ snd_midi_event_reset_decode(mdev->coder);
+ } else {
+ len = snd_midi_event_decode(mdev->coder, msg, sizeof(msg), ev);
+ if (len > 0)
--- /dev/null
+From 4384f167ce5fa7241b61bb0984d651bc528ddebe Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 16 Mar 2020 10:05:05 +0100
+Subject: ALSA: seq: virmidi: Fix running status after receiving sysex
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 4384f167ce5fa7241b61bb0984d651bc528ddebe upstream.
+
+The virmidi driver handles sysex event exceptionally in a short-cut
+snd_seq_dump_var_event() call, but this missed the reset of the
+running status. As a result, it may lead to an incomplete command
+right after the sysex when an event with the same running status was
+queued.
+
+Fix it by clearing the running status properly via alling
+snd_midi_event_reset_decode() for that code path.
+
+Reported-by: Andreas Steinmetz <ast@domdv.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
+Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/seq/seq_virmidi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/core/seq/seq_virmidi.c
++++ b/sound/core/seq/seq_virmidi.c
+@@ -95,6 +95,7 @@ static int snd_virmidi_dev_receive_event
+ if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) != SNDRV_SEQ_EVENT_LENGTH_VARIABLE)
+ continue;
+ snd_seq_dump_var_event(ev, (snd_seq_dump_func_t)snd_rawmidi_receive, vmidi->substream);
++ snd_midi_event_reset_decode(vmidi->parser);
+ } else {
+ len = snd_midi_event_decode(vmidi->parser, msg, sizeof(msg), ev);
+ if (len > 0)
xenbus-req-err-should-be-updated-before-req-state.patch
block-bfq-fix-overwrite-of-bfq_group-pointer-in-bfq_.patch
parse-maintainers-mark-as-executable.patch
+usb-disable-lpm-on-wd19-s-realtek-hub.patch
+usb-quirks-add-no_lpm-quirk-for-rtl8153-based-ethernet-adapters.patch
+usb-serial-option-add-me910g1-ecm-composition-0x110b.patch
+usb-host-xhci-plat-add-a-shutdown.patch
+usb-serial-pl2303-add-device-id-for-hp-ld381.patch
+usb-xhci-apply-xhci_suspend_delay-to-amd-xhci-controller-1022-145c.patch
+alsa-line6-fix-endless-midi-read-loop.patch
+alsa-seq-virmidi-fix-running-status-after-receiving-sysex.patch
+alsa-seq-oss-fix-running-status-after-receiving-sysex.patch
+alsa-pcm-oss-avoid-plugin-buffer-overflow.patch
+alsa-pcm-oss-remove-warning-from-snd_pcm_plug_alloc-checks.patch
--- /dev/null
+From b63e48fb50e1ca71db301ca9082befa6f16c55c4 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Wed, 5 Feb 2020 19:26:33 +0800
+Subject: USB: Disable LPM on WD19's Realtek Hub
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit b63e48fb50e1ca71db301ca9082befa6f16c55c4 upstream.
+
+Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the
+bus when bringing underlying ports from U3 to U0.
+
+Disabling LPM on the hub during setting link state is not enough, so
+let's disable LPM completely for this hub.
+
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200205112633.25995-3-kai.heng.feng@canonical.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
+@@ -378,6 +378,9 @@ static const struct usb_device_id usb_qu
+ { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
+ USB_QUIRK_IGNORE_REMOTE_WAKEUP },
+
++ /* Realtek hub in Dell WD19 (Type-C) */
++ { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
++
+ /* Action Semiconductor flash disk */
+ { USB_DEVICE(0x10d6, 0x2200), .driver_info =
+ USB_QUIRK_STRING_FETCH_255 },
--- /dev/null
+From b433e340e7565110b0ce9ca4b3e26f4b97a1decf Mon Sep 17 00:00:00 2001
+From: Ran Wang <ran.wang_1@nxp.com>
+Date: Fri, 6 Mar 2020 17:23:28 +0800
+Subject: usb: host: xhci-plat: add a shutdown
+
+From: Ran Wang <ran.wang_1@nxp.com>
+
+commit b433e340e7565110b0ce9ca4b3e26f4b97a1decf upstream.
+
+When loading new kernel via kexec, we need to shutdown host controller to
+avoid any un-expected memory accessing during new kernel boot.
+
+Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
+Cc: stable <stable@vger.kernel.org>
+Tested-by: Stephen Boyd <swboyd@chromium.org>
+Reviewed-by: Peter Chen <peter.chen@nxp.com>
+Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-plat.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/host/xhci-plat.c
++++ b/drivers/usb/host/xhci-plat.c
+@@ -443,6 +443,7 @@ MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_
+ static struct platform_driver usb_xhci_driver = {
+ .probe = xhci_plat_probe,
+ .remove = xhci_plat_remove,
++ .shutdown = usb_hcd_platform_shutdown,
+ .driver = {
+ .name = "xhci-hcd",
+ .pm = &xhci_plat_pm_ops,
--- /dev/null
+From 75d7676ead19b1fbb5e0ee934c9ccddcb666b68c Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 13 Mar 2020 13:07:08 +0100
+Subject: usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adapters
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 75d7676ead19b1fbb5e0ee934c9ccddcb666b68c upstream.
+
+We have been receiving bug reports that ethernet connections over
+RTL8153 based ethernet adapters stops working after a while with
+errors like these showing up in dmesg when the ethernet stops working:
+
+[12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout
+[12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout
+[12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout
+
+This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1
+docks and with generic USB to ethernet dongles using the RTL8153
+chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to
+the kernel commandline and all users who have tried this report that
+this fixes this.
+
+Also note that we already have an existing NO_LPM quirk for the RTL8153
+used in the Microsoft Surface Dock (where it uses a different usb-id).
+
+This commit adds a NO_LPM quirk for the generic Realtek RTL8153
+0bda:8153 usb-id, fixing the Tx timeout errors on these devices.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931
+Cc: stable@vger.kernel.org
+Cc: russianneuromancer@ya.ru
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20200313120708.100339-1-hdegoede@redhat.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
+@@ -381,6 +381,9 @@ static const struct usb_device_id usb_qu
+ /* Realtek hub in Dell WD19 (Type-C) */
+ { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+
++ /* Generic RTL8153 based ethernet adapters */
++ { USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },
++
+ /* Action Semiconductor flash disk */
+ { USB_DEVICE(0x10d6, 0x2200), .driver_info =
+ USB_QUIRK_STRING_FETCH_255 },
--- /dev/null
+From 8e852a7953be2a6ee371449f7257fe15ace6a1fc Mon Sep 17 00:00:00 2001
+From: Daniele Palmas <dnlplm@gmail.com>
+Date: Wed, 4 Mar 2020 11:43:10 +0100
+Subject: USB: serial: option: add ME910G1 ECM composition 0x110b
+
+From: Daniele Palmas <dnlplm@gmail.com>
+
+commit 8e852a7953be2a6ee371449f7257fe15ace6a1fc upstream.
+
+Add ME910G1 ECM composition 0x110b: tty, tty, tty, ecm
+
+Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
+Link: https://lore.kernel.org/r/20200304104310.2938-1-dnlplm@gmail.com
+Cc: stable <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 | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/serial/option.c
++++ b/drivers/usb/serial/option.c
+@@ -1183,6 +1183,8 @@ static const struct usb_device_id option
+ .driver_info = NCTRL(0) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x110a, 0xff), /* Telit ME910G1 */
+ .driver_info = NCTRL(0) | RSVD(3) },
++ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x110b, 0xff), /* Telit ME910G1 (ECM) */
++ .driver_info = NCTRL(0) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
+ .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910_USBCFG4),
--- /dev/null
+From cecc113c1af0dd41ccf265c1fdb84dbd05e63423 Mon Sep 17 00:00:00 2001
+From: Scott Chen <scott@labau.com.tw>
+Date: Wed, 11 Mar 2020 14:14:23 +0800
+Subject: USB: serial: pl2303: add device-id for HP LD381
+
+From: Scott Chen <scott@labau.com.tw>
+
+commit cecc113c1af0dd41ccf265c1fdb84dbd05e63423 upstream.
+
+Add a device id for HP LD381 Display
+LD381: 03f0:0f7f
+
+Signed-off-by: Scott Chen <scott@labau.com.tw>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/pl2303.c | 1 +
+ drivers/usb/serial/pl2303.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/usb/serial/pl2303.c
++++ b/drivers/usb/serial/pl2303.c
+@@ -93,6 +93,7 @@ static const struct usb_device_id id_tab
+ { USB_DEVICE(SUPERIAL_VENDOR_ID, SUPERIAL_PRODUCT_ID) },
+ { USB_DEVICE(HP_VENDOR_ID, HP_LD220_PRODUCT_ID) },
+ { USB_DEVICE(HP_VENDOR_ID, HP_LD220TA_PRODUCT_ID) },
++ { USB_DEVICE(HP_VENDOR_ID, HP_LD381_PRODUCT_ID) },
+ { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
+ { USB_DEVICE(HP_VENDOR_ID, HP_LD960TA_PRODUCT_ID) },
+ { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
+--- a/drivers/usb/serial/pl2303.h
++++ b/drivers/usb/serial/pl2303.h
+@@ -124,6 +124,7 @@
+ #define HP_LM920_PRODUCT_ID 0x026b
+ #define HP_TD620_PRODUCT_ID 0x0956
+ #define HP_LD960_PRODUCT_ID 0x0b39
++#define HP_LD381_PRODUCT_ID 0x0f7f
+ #define HP_LCM220_PRODUCT_ID 0x3139
+ #define HP_LCM960_PRODUCT_ID 0x3239
+ #define HP_LD220_PRODUCT_ID 0x3524
--- /dev/null
+From 16263abc12d09871156a1c8650fb651f0e552f5e Mon Sep 17 00:00:00 2001
+From: Alberto Mattea <alberto@mattea.info>
+Date: Fri, 6 Mar 2020 17:08:58 +0200
+Subject: usb: xhci: apply XHCI_SUSPEND_DELAY to AMD XHCI controller 1022:145c
+
+From: Alberto Mattea <alberto@mattea.info>
+
+commit 16263abc12d09871156a1c8650fb651f0e552f5e upstream.
+
+This controller timeouts during suspend (S3) with
+[ 240.521724] xhci_hcd 0000:30:00.3: WARN: xHC save state timeout
+[ 240.521729] xhci_hcd 0000:30:00.3: ERROR mismatched command completion event
+thus preventing the system from entering S3.
+Moreover it remains in an undefined state where some connected devices stop
+working until a reboot.
+Apply the XHCI_SUSPEND_DELAY quirk to make it suspend properly.
+
+CC: stable@vger.kernel.org
+Signed-off-by: Alberto Mattea <alberto@mattea.info>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20200306150858.21904-3-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -128,7 +128,8 @@ static void xhci_pci_quirks(struct devic
+ xhci->quirks |= XHCI_AMD_PLL_FIX;
+
+ if (pdev->vendor == PCI_VENDOR_ID_AMD &&
+- (pdev->device == 0x15e0 ||
++ (pdev->device == 0x145c ||
++ pdev->device == 0x15e0 ||
+ pdev->device == 0x15e1 ||
+ pdev->device == 0x43bb))
+ xhci->quirks |= XHCI_SUSPEND_DELAY;
projects / thirdparty / kernel / stable-queue.git / commitdiff
