--- /dev/null
+From 93ab3eafb0b3551c54175cb38afed3b82356a047 Mon Sep 17 00:00:00 2001
+From: Johnathon Clark <john.clark@cantab.net>
+Date: Mon, 23 Aug 2021 17:21:10 +0100
+Subject: ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup
+
+From: Johnathon Clark <john.clark@cantab.net>
+
+commit 93ab3eafb0b3551c54175cb38afed3b82356a047 upstream.
+
+This patch extends support for the HP Spectre x360 14
+amp enable quirk to support a model of the device with
+an additional subdevice ID.
+
+Signed-off-by: Johnathon Clark <john.clark@cantab.net>
+Link: https://lore.kernel.org/r/20210823162110.8870-1-john.clark@cantab.net
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -8438,6 +8438,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x87f2, "HP ProBook 640 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87f4, "HP", ALC287_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87f5, "HP", ALC287_FIXUP_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x87f6, "HP Spectre x360 14", ALC245_FIXUP_HP_X360_AMP),
+ SND_PCI_QUIRK(0x103c, 0x87f7, "HP Spectre x360 14", ALC245_FIXUP_HP_X360_AMP),
+ SND_PCI_QUIRK(0x103c, 0x8805, "HP ProBook 650 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x880d, "HP EliteBook 830 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED),
--- /dev/null
+From 13d9c6b998aaa76fd098133277a28a21f2cc2264 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 20 Aug 2021 16:32:14 +0200
+Subject: ALSA: hda/realtek: Workaround for conflicting SSID on ASUS ROG Strix G17
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 13d9c6b998aaa76fd098133277a28a21f2cc2264 upstream.
+
+ASUS ROG Strix G17 has the very same PCI and codec SSID (1043:103f) as
+ASUS TX300, and unfortunately, the existing quirk for TX300 is broken
+on ASUS ROG. Actually the device works without the quirk, so we'll
+need to clear the quirk before applying for this device.
+Since ASUS ROG has a different codec (ALC294 - while TX300 has
+ALC282), this patch adds a workaround for the device, just clearing
+the codec->fixup_id by checking the codec vendor_id.
+
+It's a bit ugly to add such a workaround there, but it seems to be the
+simplest way.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214101
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210820143214.3654-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9522,6 +9522,16 @@ static int patch_alc269(struct hda_codec
+
+ snd_hda_pick_fixup(codec, alc269_fixup_models,
+ alc269_fixup_tbl, alc269_fixups);
++ /* FIXME: both TX300 and ROG Strix G17 have the same SSID, and
++ * the quirk breaks the latter (bko#214101).
++ * Clear the wrong entry.
++ */
++ if (codec->fixup_id == ALC282_FIXUP_ASUS_TX300 &&
++ codec->core.vendor_id == 0x10ec0294) {
++ codec_dbg(codec, "Clear wrong fixup for ASUS ROG Strix G17\n");
++ codec->fixup_id = HDA_FIXUP_ID_NOT_SET;
++ }
++
+ snd_hda_pick_pin_fixup(codec, alc269_pin_fixup_tbl, alc269_fixups, true);
+ snd_hda_pick_pin_fixup(codec, alc269_fallback_pin_fixup_tbl, alc269_fixups, false);
+ snd_hda_pick_fixup(codec, NULL, alc269_fixup_vendor_tbl,
--- /dev/null
+From f3eef46f0518a2b32ca1244015820c35a22cfe4a Mon Sep 17 00:00:00 2001
+From: Zubin Mithra <zsm@chromium.org>
+Date: Fri, 27 Aug 2021 08:37:35 -0700
+Subject: ALSA: pcm: fix divide error in snd_pcm_lib_ioctl
+
+From: Zubin Mithra <zsm@chromium.org>
+
+commit f3eef46f0518a2b32ca1244015820c35a22cfe4a upstream.
+
+Syzkaller reported a divide error in snd_pcm_lib_ioctl. fifo_size
+is of type snd_pcm_uframes_t(unsigned long). If frame_size
+is 0x100000000, the error occurs.
+
+Fixes: a9960e6a293e ("ALSA: pcm: fix fifo_size frame calculation")
+Signed-off-by: Zubin Mithra <zsm@chromium.org>
+Reviewed-by: Guenter Roeck <groeck@chromium.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/pcm_lib.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/core/pcm_lib.c
++++ b/sound/core/pcm_lib.c
+@@ -1746,7 +1746,7 @@ static int snd_pcm_lib_ioctl_fifo_size(s
+ channels = params_channels(params);
+ frame_size = snd_pcm_format_size(format, channels);
+ if (frame_size > 0)
+- params->fifo_size /= (unsigned)frame_size;
++ params->fifo_size /= frame_size;
+ }
+ return 0;
+ }
--- /dev/null
+From 7af5a14371c1cf94a41f08eabb62a3faceec8911 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 24 Aug 2021 07:47:00 +0200
+Subject: ALSA: usb-audio: Fix regression on Sony WALKMAN NW-A45 DAC
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 7af5a14371c1cf94a41f08eabb62a3faceec8911 upstream.
+
+We've got a regression report for USB-audio with Sony WALKMAN NW-A45
+DAC device where no sound is audible on recent kernel. The bisection
+resulted in the code change wrt endpoint management, and the further
+debug session revealed that it was caused by the order of the USB
+audio interface. In the earlier code, we always set up the USB
+interface at first before other setups, but it was changed to be done
+at the last for UAC2/3, which is more standard way, while keeping the
+old way for UAC1. OTOH, this device seems requiring the setup of the
+interface at first just like UAC1.
+
+This patch works around the regression by applying the interface setup
+specifically for the WALKMAN at the beginning of the endpoint setup
+procedure. This change is written straightforwardly to be easily
+backported in old kernels. A further cleanup to move the workaround
+into a generic quirk section will follow in a later patch.
+
+Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
+Cc: <stable@vger.kernel.org>
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214105
+Link: https://lore.kernel.org/r/20210824054700.8236-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/endpoint.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -1287,6 +1287,11 @@ int snd_usb_endpoint_configure(struct sn
+ * to be set up before parameter setups
+ */
+ iface_first = ep->cur_audiofmt->protocol == UAC_VERSION_1;
++ /* Workaround for Sony WALKMAN NW-A45 DAC;
++ * it requires the interface setup at first like UAC1
++ */
++ if (chip->usb_id == USB_ID(0x054c, 0x0b8c))
++ iface_first = true;
+ if (iface_first) {
+ err = endpoint_set_interface(chip, ep, true);
+ if (err < 0)
--- /dev/null
+From 4267c5a8f3133db0572cd9abee059b42cafbbdad Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 27 Aug 2021 22:33:11 +0200
+Subject: ALSA: usb-audio: Work around for XRUN with low latency playback
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 4267c5a8f3133db0572cd9abee059b42cafbbdad upstream.
+
+The recent change for low latency playback works in most of test cases
+but it turned out still to hit errors on some use cases, most notably
+with JACK with small buffer sizes. This is because USB-audio driver
+fills up and submits full URBs at the beginning, while the URBs would
+return immediately and try to fill more -- that can easily trigger
+XRUN. It was more or less expected, but in the small buffer size, the
+problem became pretty obvious.
+
+Fixing this behavior properly would require the change of the
+fundamental driver design, so it's no trivial task, unfortunately.
+Instead, here we work around the problem just by switching back to the
+old method when the given configuration is too fragile with the low
+latency stream handling. As a threshold, we calculate the total
+buffer bytes in all plus one URBs, and check whether it's beyond the
+PCM buffer bytes. The one extra URB is needed because XRUN happens at
+the next submission after the first round.
+
+Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210827203311.5987-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/card.h | 2 ++
+ sound/usb/endpoint.c | 4 ++++
+ sound/usb/pcm.c | 13 +++++++++++--
+ 3 files changed, 17 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/card.h
++++ b/sound/usb/card.h
+@@ -94,6 +94,7 @@ struct snd_usb_endpoint {
+ struct list_head ready_playback_urbs; /* playback URB FIFO for implicit fb */
+
+ unsigned int nurbs; /* # urbs */
++ unsigned int nominal_queue_size; /* total buffer sizes in URBs */
+ unsigned long active_mask; /* bitmask of active urbs */
+ unsigned long unlink_mask; /* bitmask of unlinked urbs */
+ char *syncbuf; /* sync buffer for all sync URBs */
+@@ -187,6 +188,7 @@ struct snd_usb_substream {
+ } dsd_dop;
+
+ bool trigger_tstamp_pending_update; /* trigger timestamp being updated from initial estimate */
++ bool early_playback_start; /* early start needed for playback? */
+ struct media_ctl *media_ctl;
+ };
+
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -1126,6 +1126,10 @@ static int data_ep_set_params(struct snd
+ INIT_LIST_HEAD(&u->ready_list);
+ }
+
++ /* total buffer bytes of all URBs plus the next queue;
++ * referred in pcm.c
++ */
++ ep->nominal_queue_size = maxsize * urb_packs * (ep->nurbs + 1);
+ return 0;
+
+ out_of_memory:
+--- a/sound/usb/pcm.c
++++ b/sound/usb/pcm.c
+@@ -614,6 +614,14 @@ static int snd_usb_pcm_prepare(struct sn
+ subs->period_elapsed_pending = 0;
+ runtime->delay = 0;
+
++ /* check whether early start is needed for playback stream */
++ subs->early_playback_start =
++ subs->direction == SNDRV_PCM_STREAM_PLAYBACK &&
++ subs->data_endpoint->nominal_queue_size >= subs->buffer_bytes;
++
++ if (subs->early_playback_start)
++ ret = start_endpoints(subs);
++
+ unlock:
+ snd_usb_unlock_shutdown(chip);
+ return ret;
+@@ -1394,7 +1402,7 @@ static void prepare_playback_urb(struct
+ subs->trigger_tstamp_pending_update = false;
+ }
+
+- if (period_elapsed && !subs->running) {
++ if (period_elapsed && !subs->running && !subs->early_playback_start) {
+ subs->period_elapsed_pending = 1;
+ period_elapsed = 0;
+ }
+@@ -1448,7 +1456,8 @@ static int snd_usb_substream_playback_tr
+ prepare_playback_urb,
+ retire_playback_urb,
+ subs);
+- if (cmd == SNDRV_PCM_TRIGGER_START) {
++ if (!subs->early_playback_start &&
++ cmd == SNDRV_PCM_TRIGGER_START) {
+ err = start_endpoints(subs);
+ if (err < 0) {
+ snd_usb_endpoint_set_callback(subs->data_endpoint,
--- /dev/null
+From 5049307d37a760e304ad191c5dc7c6851266d2f8 Mon Sep 17 00:00:00 2001
+From: Michal Kubecek <mkubecek@suse.cz>
+Date: Wed, 1 Sep 2021 12:35:49 -0400
+Subject: HID: usbhid: Fix flood of "control queue full" messages
+
+From: Michal Kubecek <mkubecek@suse.cz>
+
+commit 5049307d37a760e304ad191c5dc7c6851266d2f8 upstream.
+
+[patch description by Alan Stern]
+
+Commit 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength
+for control transfers") causes control URB submissions to fail if the
+transfer_buffer_length value disagrees with the setup packet's wLength
+valuel. Unfortunately, it turns out that the usbhid can trigger this
+failure mode when it submits a control request for an input report: It
+pads the transfer buffer size to a multiple of the maxpacket value but
+does not increase wLength correspondingly.
+
+These failures have caused problems for people using an APS UPC, in
+the form of a flood of log messages resembling:
+
+ hid-generic 0003:051D:0002.0002: control queue full
+
+This patch fixes the problem by setting the wLength value equal to the
+padded transfer_buffer_length value in hid_submit_ctrl(). As a nice
+bonus, the code which stores the transfer_buffer_length value is now
+shared between the two branches of an "if" statement, so it can be
+de-duplicated.
+
+Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Fixes: 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers")
+Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
+Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/usbhid/hid-core.c | 15 +++++++--------
+ 1 file changed, 7 insertions(+), 8 deletions(-)
+
+--- a/drivers/hid/usbhid/hid-core.c
++++ b/drivers/hid/usbhid/hid-core.c
+@@ -377,27 +377,26 @@ static int hid_submit_ctrl(struct hid_de
+ len = hid_report_len(report);
+ if (dir == USB_DIR_OUT) {
+ usbhid->urbctrl->pipe = usb_sndctrlpipe(hid_to_usb_dev(hid), 0);
+- usbhid->urbctrl->transfer_buffer_length = len;
+ if (raw_report) {
+ memcpy(usbhid->ctrlbuf, raw_report, len);
+ kfree(raw_report);
+ usbhid->ctrl[usbhid->ctrltail].raw_report = NULL;
+ }
+ } else {
+- int maxpacket, padlen;
++ int maxpacket;
+
+ usbhid->urbctrl->pipe = usb_rcvctrlpipe(hid_to_usb_dev(hid), 0);
+ maxpacket = usb_maxpacket(hid_to_usb_dev(hid),
+ usbhid->urbctrl->pipe, 0);
+ if (maxpacket > 0) {
+- padlen = DIV_ROUND_UP(len, maxpacket);
+- padlen *= maxpacket;
+- if (padlen > usbhid->bufsize)
+- padlen = usbhid->bufsize;
++ len = DIV_ROUND_UP(len, maxpacket);
++ len *= maxpacket;
++ if (len > usbhid->bufsize)
++ len = usbhid->bufsize;
+ } else
+- padlen = 0;
+- usbhid->urbctrl->transfer_buffer_length = padlen;
++ len = 0;
+ }
++ usbhid->urbctrl->transfer_buffer_length = len;
+ usbhid->urbctrl->dev = hid_to_usb_dev(hid);
+
+ usbhid->cr->bRequestType = USB_TYPE_CLASS | USB_RECIP_INTERFACE | dir;
--- /dev/null
+From 0a824efdb724e07574bafcd2c2486b2a3de35ff6 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Wed, 1 Sep 2021 12:36:00 -0400
+Subject: HID: usbhid: Fix warning caused by 0-length input reports
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 0a824efdb724e07574bafcd2c2486b2a3de35ff6 upstream.
+
+Syzbot found a warning caused by hid_submit_ctrl() submitting a
+control request to transfer a 0-length input report:
+
+ usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType a1
+
+(The warning message is a little difficult to understand. It means
+that the control request claims to be for an IN transfer but this
+contradicts the USB spec, which requires 0-length control transfers
+always to be in the OUT direction.)
+
+Now, a zero-length report isn't good for anything and there's no
+reason for a device to have one, but the fuzzer likes to pick out
+these weird edge cases. In the future, perhaps we will decide to
+reject 0-length reports at probe time. For now, the simplest approach
+for avoiding these warnings is to pretend that the report actually has
+length 1.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com
+Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
+Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/usbhid/hid-core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/hid/usbhid/hid-core.c
++++ b/drivers/hid/usbhid/hid-core.c
+@@ -389,6 +389,7 @@ static int hid_submit_ctrl(struct hid_de
+ maxpacket = usb_maxpacket(hid_to_usb_dev(hid),
+ usbhid->urbctrl->pipe, 0);
+ if (maxpacket > 0) {
++ len += (len == 0); /* Don't allow 0-length reports */
+ len = DIV_ROUND_UP(len, maxpacket);
+ len *= maxpacket;
+ if (len > usbhid->bufsize)
ext4-fix-race-writing-to-an-inline_data-file-while-its-xattrs-are-changing.patch
ext4-fix-e2fsprogs-checksum-failure-for-mounted-filesystem.patch
xtensa-fix-kconfig-unmet-dependency-warning-for-have_futex_cmpxchg.patch
+usb-serial-pl2303-fix-gl-type-detection.patch
+usb-serial-cp210x-fix-control-characters-error-handling.patch
+usb-serial-cp210x-fix-flow-control-error-handling.patch
+hid-usbhid-fix-flood-of-control-queue-full-messages.patch
+hid-usbhid-fix-warning-caused-by-0-length-input-reports.patch
+alsa-hda-realtek-quirk-for-hp-spectre-x360-14-amp-setup.patch
+alsa-usb-audio-fix-regression-on-sony-walkman-nw-a45-dac.patch
+alsa-hda-realtek-workaround-for-conflicting-ssid-on-asus-rog-strix-g17.patch
+alsa-pcm-fix-divide-error-in-snd_pcm_lib_ioctl.patch
+alsa-usb-audio-work-around-for-xrun-with-low-latency-playback.patch
--- /dev/null
+From 2d9a00705910ccea2dc5d9cba5469ff2de72fc87 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 5 Jul 2021 10:20:10 +0200
+Subject: USB: serial: cp210x: fix control-characters error handling
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 2d9a00705910ccea2dc5d9cba5469ff2de72fc87 upstream.
+
+In the unlikely event that setting the software flow-control characters
+fails the other flow-control settings should still be updated (just like
+all other terminal settings).
+
+Move out the error message printed by the set_chars() helper to make it
+more obvious that this is intentional.
+
+Fixes: 7748feffcd80 ("USB: serial: cp210x: add support for software flow control")
+Cc: stable@vger.kernel.org # 5.11
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/cp210x.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/serial/cp210x.c
++++ b/drivers/usb/serial/cp210x.c
+@@ -1164,10 +1164,8 @@ static int cp210x_set_chars(struct usb_s
+
+ kfree(dmabuf);
+
+- if (result < 0) {
+- dev_err(&port->dev, "failed to set special chars: %d\n", result);
++ if (result < 0)
+ return result;
+- }
+
+ return 0;
+ }
+@@ -1219,8 +1217,10 @@ static void cp210x_set_flow_control(stru
+ chars.bXoffChar = STOP_CHAR(tty);
+
+ ret = cp210x_set_chars(port, &chars);
+- if (ret)
+- return;
++ if (ret) {
++ dev_err(&port->dev, "failed to set special chars: %d\n",
++ ret);
++ }
+ }
+
+ mutex_lock(&port_priv->mutex);
--- /dev/null
+From ba4bbdabecd11530dca78dbae3ee7e51ffdc0a06 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 5 Jul 2021 10:20:11 +0200
+Subject: USB: serial: cp210x: fix flow-control error handling
+
+From: Johan Hovold <johan@kernel.org>
+
+commit ba4bbdabecd11530dca78dbae3ee7e51ffdc0a06 upstream.
+
+Make sure that the driver crtscts state is not updated in the unlikely
+event that the flow-control request fails. Not doing so could break RTS
+control.
+
+Fixes: 5951b8508855 ("USB: serial: cp210x: suppress modem-control errors")
+Cc: stable@vger.kernel.org # 5.11
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/cp210x.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/serial/cp210x.c
++++ b/drivers/usb/serial/cp210x.c
+@@ -1190,6 +1190,7 @@ static void cp210x_set_flow_control(stru
+ struct cp210x_flow_ctl flow_ctl;
+ u32 flow_repl;
+ u32 ctl_hs;
++ bool crtscts;
+ int ret;
+
+ /*
+@@ -1249,14 +1250,14 @@ static void cp210x_set_flow_control(stru
+ flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ else
+ flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
+- port_priv->crtscts = true;
++ crtscts = true;
+ } else {
+ ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
+ if (port_priv->rts)
+ flow_repl |= CP210X_SERIAL_RTS_ACTIVE;
+ else
+ flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
+- port_priv->crtscts = false;
++ crtscts = false;
+ }
+
+ if (I_IXOFF(tty)) {
+@@ -1279,8 +1280,12 @@ static void cp210x_set_flow_control(stru
+ flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs);
+ flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
+
+- cp210x_write_reg_block(port, CP210X_SET_FLOW, &flow_ctl,
++ ret = cp210x_write_reg_block(port, CP210X_SET_FLOW, &flow_ctl,
+ sizeof(flow_ctl));
++ if (ret)
++ goto out_unlock;
++
++ port_priv->crtscts = crtscts;
+ out_unlock:
+ mutex_unlock(&port_priv->mutex);
+ }
--- /dev/null
+From dcf097e7d21fbdfbf20e473ac155f4d154018374 Mon Sep 17 00:00:00 2001
+From: Robert Marko <robert.marko@sartura.hr>
+Date: Thu, 26 Aug 2021 13:02:39 +0200
+Subject: USB: serial: pl2303: fix GL type detection
+
+From: Robert Marko <robert.marko@sartura.hr>
+
+commit dcf097e7d21fbdfbf20e473ac155f4d154018374 upstream.
+
+At least some PL2303GL have a bcdDevice of 0x405 instead of 0x100 as the
+datasheet claims. Add it to the list of known release numbers for the
+HXN (G) type.
+
+Fixes: 894758d0571d ("USB: serial: pl2303: tighten type HXN (G) detection")
+Signed-off-by: Robert Marko <robert.marko@sartura.hr>
+Cc: stable@vger.kernel.org # 5.13
+Link: https://lore.kernel.org/r/20210826110239.5269-1-robert.marko@sartura.hr
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/pl2303.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/serial/pl2303.c
++++ b/drivers/usb/serial/pl2303.c
+@@ -433,6 +433,7 @@ static int pl2303_detect_type(struct usb
+ switch (bcdDevice) {
+ case 0x100:
+ case 0x305:
++ case 0x405:
+ /*
+ * Assume it's an HXN-type if the device doesn't
+ * support the old read request value.
projects / thirdparty / kernel / stable-queue.git / commitdiff
