From: Greg Kroah-Hartman Date: Mon, 23 Mar 2020 12:32:32 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.19.113~33 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7ad8289c2dc60ff6980c53c98c3cc15bbf509305;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: alsa-line6-fix-endless-midi-read-loop.patch alsa-pcm-oss-avoid-plugin-buffer-overflow.patch alsa-pcm-oss-remove-warning-from-snd_pcm_plug_alloc-checks.patch alsa-seq-oss-fix-running-status-after-receiving-sysex.patch alsa-seq-virmidi-fix-running-status-after-receiving-sysex.patch usb-disable-lpm-on-wd19-s-realtek-hub.patch usb-host-xhci-plat-add-a-shutdown.patch usb-quirks-add-no_lpm-quirk-for-rtl8153-based-ethernet-adapters.patch usb-serial-option-add-me910g1-ecm-composition-0x110b.patch usb-serial-pl2303-add-device-id-for-hp-ld381.patch --- diff --git a/queue-4.4/alsa-line6-fix-endless-midi-read-loop.patch b/queue-4.4/alsa-line6-fix-endless-midi-read-loop.patch new file mode 100644 index 00000000000..b57d8b3582f --- /dev/null +++ b/queue-4.4/alsa-line6-fix-endless-midi-read-loop.patch @@ -0,0 +1,55 @@ +From d683469b3c93d7e2afd39e6e1970f24700eb7a68 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 9 Mar 2020 10:59:22 +0100 +Subject: ALSA: line6: Fix endless MIDI read loop + +From: Takashi Iwai + +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: +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -283,7 +283,7 @@ static void line6_data_received(struct u + line6_midibuf_read(mb, line6->buffer_message, + LINE6_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 diff --git a/queue-4.4/alsa-pcm-oss-avoid-plugin-buffer-overflow.patch b/queue-4.4/alsa-pcm-oss-avoid-plugin-buffer-overflow.patch new file mode 100644 index 00000000000..ccbf845f15e --- /dev/null +++ b/queue-4.4/alsa-pcm-oss-avoid-plugin-buffer-overflow.patch @@ -0,0 +1,70 @@ +From f2ecf903ef06eb1bbbfa969db9889643d487e73a Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 9 Mar 2020 09:21:48 +0100 +Subject: ALSA: pcm: oss: Avoid plugin buffer overflow + +From: Takashi Iwai + +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: +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/alsa-pcm-oss-remove-warning-from-snd_pcm_plug_alloc-checks.patch b/queue-4.4/alsa-pcm-oss-remove-warning-from-snd_pcm_plug_alloc-checks.patch new file mode 100644 index 00000000000..2b7a168514c --- /dev/null +++ b/queue-4.4/alsa-pcm-oss-remove-warning-from-snd_pcm_plug_alloc-checks.patch @@ -0,0 +1,46 @@ +From 5461e0530c222129dfc941058be114b5cbc00837 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 12 Mar 2020 16:57:30 +0100 +Subject: ALSA: pcm: oss: Remove WARNING from snd_pcm_plug_alloc() checks + +From: Takashi Iwai + +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: +Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/alsa-seq-oss-fix-running-status-after-receiving-sysex.patch b/queue-4.4/alsa-seq-oss-fix-running-status-after-receiving-sysex.patch new file mode 100644 index 00000000000..e5c94e16789 --- /dev/null +++ b/queue-4.4/alsa-seq-oss-fix-running-status-after-receiving-sysex.patch @@ -0,0 +1,34 @@ +From 6c3171ef76a0bad892050f6959a7eac02fb16df7 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 16 Mar 2020 10:05:06 +0100 +Subject: ALSA: seq: oss: Fix running status after receiving sysex + +From: Takashi Iwai + +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: +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/alsa-seq-virmidi-fix-running-status-after-receiving-sysex.patch b/queue-4.4/alsa-seq-virmidi-fix-running-status-after-receiving-sysex.patch new file mode 100644 index 00000000000..ed439db4a1f --- /dev/null +++ b/queue-4.4/alsa-seq-virmidi-fix-running-status-after-receiving-sysex.patch @@ -0,0 +1,39 @@ +From 4384f167ce5fa7241b61bb0984d651bc528ddebe Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 16 Mar 2020 10:05:05 +0100 +Subject: ALSA: seq: virmidi: Fix running status after receiving sysex + +From: Takashi Iwai + +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 +Cc: +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/series b/queue-4.4/series index be87440f641..7df5e477d82 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -5,3 +5,13 @@ spi-zynqmp-remove-entry-that-causes-a-cs-glitch.patch drm-exynos-dsi-propagate-error-value-and-silence-mea.patch drm-exynos-dsi-fix-workaround-for-the-legacy-clock-n.patch altera-stapl-altera_get_note-prevent-write-beyond-en.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 +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 diff --git a/queue-4.4/usb-disable-lpm-on-wd19-s-realtek-hub.patch b/queue-4.4/usb-disable-lpm-on-wd19-s-realtek-hub.patch new file mode 100644 index 00000000000..55eb3f897ad --- /dev/null +++ b/queue-4.4/usb-disable-lpm-on-wd19-s-realtek-hub.patch @@ -0,0 +1,37 @@ +From b63e48fb50e1ca71db301ca9082befa6f16c55c4 Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Wed, 5 Feb 2020 19:26:33 +0800 +Subject: USB: Disable LPM on WD19's Realtek Hub + +From: Kai-Heng Feng + +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 +Signed-off-by: Kai-Heng Feng +Cc: stable +Link: https://lore.kernel.org/r/20200205112633.25995-3-kai.heng.feng@canonical.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 +@@ -229,6 +229,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 }, diff --git a/queue-4.4/usb-host-xhci-plat-add-a-shutdown.patch b/queue-4.4/usb-host-xhci-plat-add-a-shutdown.patch new file mode 100644 index 00000000000..f4538df11dd --- /dev/null +++ b/queue-4.4/usb-host-xhci-plat-add-a-shutdown.patch @@ -0,0 +1,33 @@ +From b433e340e7565110b0ce9ca4b3e26f4b97a1decf Mon Sep 17 00:00:00 2001 +From: Ran Wang +Date: Fri, 6 Mar 2020 17:23:28 +0800 +Subject: usb: host: xhci-plat: add a shutdown + +From: Ran Wang + +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 +Cc: stable +Tested-by: Stephen Boyd +Reviewed-by: Peter Chen +Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.com +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -284,6 +284,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 = DEV_PM_OPS, diff --git a/queue-4.4/usb-quirks-add-no_lpm-quirk-for-rtl8153-based-ethernet-adapters.patch b/queue-4.4/usb-quirks-add-no_lpm-quirk-for-rtl8153-based-ethernet-adapters.patch new file mode 100644 index 00000000000..e7796dc8f7f --- /dev/null +++ b/queue-4.4/usb-quirks-add-no_lpm-quirk-for-rtl8153-based-ethernet-adapters.patch @@ -0,0 +1,52 @@ +From 75d7676ead19b1fbb5e0ee934c9ccddcb666b68c Mon Sep 17 00:00:00 2001 +From: Hans de Goede +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 + +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 +Link: https://lore.kernel.org/r/20200313120708.100339-1-hdegoede@redhat.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 +@@ -232,6 +232,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 }, diff --git a/queue-4.4/usb-serial-option-add-me910g1-ecm-composition-0x110b.patch b/queue-4.4/usb-serial-option-add-me910g1-ecm-composition-0x110b.patch new file mode 100644 index 00000000000..2f79e1384ef --- /dev/null +++ b/queue-4.4/usb-serial-option-add-me910g1-ecm-composition-0x110b.patch @@ -0,0 +1,32 @@ +From 8e852a7953be2a6ee371449f7257fe15ace6a1fc Mon Sep 17 00:00:00 2001 +From: Daniele Palmas +Date: Wed, 4 Mar 2020 11:43:10 +0100 +Subject: USB: serial: option: add ME910G1 ECM composition 0x110b + +From: Daniele Palmas + +commit 8e852a7953be2a6ee371449f7257fe15ace6a1fc upstream. + +Add ME910G1 ECM composition 0x110b: tty, tty, tty, ecm + +Signed-off-by: Daniele Palmas +Link: https://lore.kernel.org/r/20200304104310.2938-1-dnlplm@gmail.com +Cc: stable +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 +@@ -1172,6 +1172,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), diff --git a/queue-4.4/usb-serial-pl2303-add-device-id-for-hp-ld381.patch b/queue-4.4/usb-serial-pl2303-add-device-id-for-hp-ld381.patch new file mode 100644 index 00000000000..6e1506a1dba --- /dev/null +++ b/queue-4.4/usb-serial-pl2303-add-device-id-for-hp-ld381.patch @@ -0,0 +1,42 @@ +From cecc113c1af0dd41ccf265c1fdb84dbd05e63423 Mon Sep 17 00:00:00 2001 +From: Scott Chen +Date: Wed, 11 Mar 2020 14:14:23 +0800 +Subject: USB: serial: pl2303: add device-id for HP LD381 + +From: Scott Chen + +commit cecc113c1af0dd41ccf265c1fdb84dbd05e63423 upstream. + +Add a device id for HP LD381 Display +LD381: 03f0:0f7f + +Signed-off-by: Scott Chen +Cc: stable +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -88,6 +88,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 +@@ -128,6 +128,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