From: Greg Kroah-Hartman Date: Mon, 6 Sep 2021 08:08:15 +0000 (+0200) Subject: 5.14-stable patches X-Git-Tag: v5.10.63~18 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=843407c91aab821e4e0be50a87eb8c10398ee432;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: alsa-hda-realtek-quirk-for-hp-spectre-x360-14-amp-setup.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-fix-regression-on-sony-walkman-nw-a45-dac.patch alsa-usb-audio-work-around-for-xrun-with-low-latency-playback.patch hid-usbhid-fix-flood-of-control-queue-full-messages.patch hid-usbhid-fix-warning-caused-by-0-length-input-reports.patch usb-serial-cp210x-fix-control-characters-error-handling.patch usb-serial-cp210x-fix-flow-control-error-handling.patch usb-serial-pl2303-fix-gl-type-detection.patch --- diff --git a/queue-5.14/alsa-hda-realtek-quirk-for-hp-spectre-x360-14-amp-setup.patch b/queue-5.14/alsa-hda-realtek-quirk-for-hp-spectre-x360-14-amp-setup.patch new file mode 100644 index 00000000000..efdebada885 --- /dev/null +++ b/queue-5.14/alsa-hda-realtek-quirk-for-hp-spectre-x360-14-amp-setup.patch @@ -0,0 +1,32 @@ +From 93ab3eafb0b3551c54175cb38afed3b82356a047 Mon Sep 17 00:00:00 2001 +From: Johnathon Clark +Date: Mon, 23 Aug 2021 17:21:10 +0100 +Subject: ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup + +From: Johnathon Clark + +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 +Link: https://lore.kernel.org/r/20210823162110.8870-1-john.clark@cantab.net +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-5.14/alsa-hda-realtek-workaround-for-conflicting-ssid-on-asus-rog-strix-g17.patch b/queue-5.14/alsa-hda-realtek-workaround-for-conflicting-ssid-on-asus-rog-strix-g17.patch new file mode 100644 index 00000000000..f746a648ecc --- /dev/null +++ b/queue-5.14/alsa-hda-realtek-workaround-for-conflicting-ssid-on-asus-rog-strix-g17.patch @@ -0,0 +1,48 @@ +From 13d9c6b998aaa76fd098133277a28a21f2cc2264 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +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 + +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: +Link: https://lore.kernel.org/r/20210820143214.3654-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.14/alsa-pcm-fix-divide-error-in-snd_pcm_lib_ioctl.patch b/queue-5.14/alsa-pcm-fix-divide-error-in-snd_pcm_lib_ioctl.patch new file mode 100644 index 00000000000..ceeae309bf5 --- /dev/null +++ b/queue-5.14/alsa-pcm-fix-divide-error-in-snd_pcm_lib_ioctl.patch @@ -0,0 +1,35 @@ +From f3eef46f0518a2b32ca1244015820c35a22cfe4a Mon Sep 17 00:00:00 2001 +From: Zubin Mithra +Date: Fri, 27 Aug 2021 08:37:35 -0700 +Subject: ALSA: pcm: fix divide error in snd_pcm_lib_ioctl + +From: Zubin Mithra + +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 +Reviewed-by: Guenter Roeck +Cc: +Link: https://lore.kernel.org/r/20210827153735.789452-1-zsm@chromium.org +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.14/alsa-usb-audio-fix-regression-on-sony-walkman-nw-a45-dac.patch b/queue-5.14/alsa-usb-audio-fix-regression-on-sony-walkman-nw-a45-dac.patch new file mode 100644 index 00000000000..1c05d6ebca2 --- /dev/null +++ b/queue-5.14/alsa-usb-audio-fix-regression-on-sony-walkman-nw-a45-dac.patch @@ -0,0 +1,49 @@ +From 7af5a14371c1cf94a41f08eabb62a3faceec8911 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 24 Aug 2021 07:47:00 +0200 +Subject: ALSA: usb-audio: Fix regression on Sony WALKMAN NW-A45 DAC + +From: Takashi Iwai + +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: +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.14/alsa-usb-audio-work-around-for-xrun-with-low-latency-playback.patch b/queue-5.14/alsa-usb-audio-work-around-for-xrun-with-low-latency-playback.patch new file mode 100644 index 00000000000..05e5ca16117 --- /dev/null +++ b/queue-5.14/alsa-usb-audio-work-around-for-xrun-with-low-latency-playback.patch @@ -0,0 +1,104 @@ +From 4267c5a8f3133db0572cd9abee059b42cafbbdad Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 27 Aug 2021 22:33:11 +0200 +Subject: ALSA: usb-audio: Work around for XRUN with low latency playback + +From: Takashi Iwai + +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: +Link: https://lore.kernel.org/r/20210827203311.5987-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.14/hid-usbhid-fix-flood-of-control-queue-full-messages.patch b/queue-5.14/hid-usbhid-fix-flood-of-control-queue-full-messages.patch new file mode 100644 index 00000000000..b4b36c28e34 --- /dev/null +++ b/queue-5.14/hid-usbhid-fix-flood-of-control-queue-full-messages.patch @@ -0,0 +1,80 @@ +From 5049307d37a760e304ad191c5dc7c6851266d2f8 Mon Sep 17 00:00:00 2001 +From: Michal Kubecek +Date: Wed, 1 Sep 2021 12:35:49 -0400 +Subject: HID: usbhid: Fix flood of "control queue full" messages + +From: Michal Kubecek + +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 +Signed-off-by: Alan Stern +Fixes: 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers") +Tested-by: Oleksandr Natalenko +Tested-by: Benjamin Tissoires +Acked-by: Benjamin Tissoires +Cc: stable@vger.kernel.org +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.14/hid-usbhid-fix-warning-caused-by-0-length-input-reports.patch b/queue-5.14/hid-usbhid-fix-warning-caused-by-0-length-input-reports.patch new file mode 100644 index 00000000000..dac33ed5095 --- /dev/null +++ b/queue-5.14/hid-usbhid-fix-warning-caused-by-0-length-input-reports.patch @@ -0,0 +1,48 @@ +From 0a824efdb724e07574bafcd2c2486b2a3de35ff6 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Wed, 1 Sep 2021 12:36:00 -0400 +Subject: HID: usbhid: Fix warning caused by 0-length input reports + +From: Alan Stern + +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 +Reported-and-tested-by: syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com +Tested-by: Oleksandr Natalenko +Tested-by: Benjamin Tissoires +Acked-by: Benjamin Tissoires +Cc: stable@vger.kernel.org +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.14/series b/queue-5.14/series index a874fc92710..d3dbc010dc6 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -1,3 +1,13 @@ 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 diff --git a/queue-5.14/usb-serial-cp210x-fix-control-characters-error-handling.patch b/queue-5.14/usb-serial-cp210x-fix-control-characters-error-handling.patch new file mode 100644 index 00000000000..694f2cf494c --- /dev/null +++ b/queue-5.14/usb-serial-cp210x-fix-control-characters-error-handling.patch @@ -0,0 +1,52 @@ +From 2d9a00705910ccea2dc5d9cba5469ff2de72fc87 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Mon, 5 Jul 2021 10:20:10 +0200 +Subject: USB: serial: cp210x: fix control-characters error handling + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.14/usb-serial-cp210x-fix-flow-control-error-handling.patch b/queue-5.14/usb-serial-cp210x-fix-flow-control-error-handling.patch new file mode 100644 index 00000000000..d282a9f971e --- /dev/null +++ b/queue-5.14/usb-serial-cp210x-fix-flow-control-error-handling.patch @@ -0,0 +1,63 @@ +From ba4bbdabecd11530dca78dbae3ee7e51ffdc0a06 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Mon, 5 Jul 2021 10:20:11 +0200 +Subject: USB: serial: cp210x: fix flow-control error handling + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.14/usb-serial-pl2303-fix-gl-type-detection.patch b/queue-5.14/usb-serial-pl2303-fix-gl-type-detection.patch new file mode 100644 index 00000000000..7f324c454b9 --- /dev/null +++ b/queue-5.14/usb-serial-pl2303-fix-gl-type-detection.patch @@ -0,0 +1,33 @@ +From dcf097e7d21fbdfbf20e473ac155f4d154018374 Mon Sep 17 00:00:00 2001 +From: Robert Marko +Date: Thu, 26 Aug 2021 13:02:39 +0200 +Subject: USB: serial: pl2303: fix GL type detection + +From: Robert Marko + +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 +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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.