From: Greg Kroah-Hartman Date: Wed, 5 May 2021 08:15:20 +0000 (+0200) Subject: 5.12-stable patches X-Git-Tag: v4.19.190~11 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=daf32a246014210bea767b33f61d56506ed1c2a8;p=thirdparty%2Fkernel%2Fstable-queue.git 5.12-stable patches added patches: alsa-usb-audio-add-midi-quirk-for-vox-tonelab-ex.patch alsa-usb-audio-fix-implicit-sync-clearance-at-stopping-stream.patch asoc-ak4458-add-module_device_table.patch asoc-ak5558-add-module_device_table.patch ovl-allow-upperdir-inside-lowerdir.patch ovl-fix-leaked-dentry.patch platform-x86-thinkpad_acpi-correct-thermal-sensor-allocation.patch usb-add-lpm-quirk-for-lenovo-thinkpad-usb-c-dock-gen2-ethernet.patch usb-add-reset-resume-quirk-for-wd19-s-realtek-hub.patch --- diff --git a/queue-5.12/alsa-usb-audio-add-midi-quirk-for-vox-tonelab-ex.patch b/queue-5.12/alsa-usb-audio-add-midi-quirk-for-vox-tonelab-ex.patch new file mode 100644 index 00000000000..65a8f1aa787 --- /dev/null +++ b/queue-5.12/alsa-usb-audio-add-midi-quirk-for-vox-tonelab-ex.patch @@ -0,0 +1,40 @@ +From 64f40f9be14106e7df0098c427cb60be645bddb7 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 7 Apr 2021 16:45:49 +0200 +Subject: ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX + +From: Takashi Iwai + +commit 64f40f9be14106e7df0098c427cb60be645bddb7 upstream. + +ToneLab EX guitar pedal device requires the same quirk like ToneLab ST +for supporting the MIDI. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212593 +Cc: +Link: https://lore.kernel.org/r/20210407144549.1530-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks-table.h | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/sound/usb/quirks-table.h ++++ b/sound/usb/quirks-table.h +@@ -2376,6 +2376,16 @@ YAMAHA_DEVICE(0x7010, "UB99"), + } + }, + ++{ ++ USB_DEVICE_VENDOR_SPEC(0x0944, 0x0204), ++ .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { ++ .vendor_name = "KORG, Inc.", ++ /* .product_name = "ToneLab EX", */ ++ .ifnum = 3, ++ .type = QUIRK_MIDI_STANDARD_INTERFACE, ++ } ++}, ++ + /* AKAI devices */ + { + USB_DEVICE(0x09e8, 0x0062), diff --git a/queue-5.12/alsa-usb-audio-fix-implicit-sync-clearance-at-stopping-stream.patch b/queue-5.12/alsa-usb-audio-fix-implicit-sync-clearance-at-stopping-stream.patch new file mode 100644 index 00000000000..9d9bdf09165 --- /dev/null +++ b/queue-5.12/alsa-usb-audio-fix-implicit-sync-clearance-at-stopping-stream.patch @@ -0,0 +1,48 @@ +From 988cc17552606be67a956cf8cd6ff504cfc5d643 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 26 Apr 2021 08:33:49 +0200 +Subject: ALSA: usb-audio: Fix implicit sync clearance at stopping stream + +From: Takashi Iwai + +commit 988cc17552606be67a956cf8cd6ff504cfc5d643 upstream. + +The recent endpoint management change for implicit feedback mode added +a clearance of ep->sync_sink (formerly ep->sync_slave) pointer at +snd_usb_endpoint_stop() to assure no leftover for the feedback from +the already stopped capture stream. This turned out to cause a +regression, however, when full-duplex streams were running and only a +capture was stopped. Because of the above clearance of ep->sync_sink +pointer, no more feedback is done, hence the playback will stall. + +This patch fixes the ep->sync_sink clearance to be done only after all +endpoints are released, for addressing the regression. + +Reported-and-tested-by: Lucas Endres +Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") +Cc: +Link: https://lore.kernel.org/r/20210426063349.18601-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/endpoint.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/sound/usb/endpoint.c ++++ b/sound/usb/endpoint.c +@@ -1442,11 +1442,11 @@ void snd_usb_endpoint_stop(struct snd_us + if (snd_BUG_ON(!atomic_read(&ep->running))) + return; + +- if (ep->sync_source) +- WRITE_ONCE(ep->sync_source->sync_sink, NULL); +- +- if (!atomic_dec_return(&ep->running)) ++ if (!atomic_dec_return(&ep->running)) { ++ if (ep->sync_source) ++ WRITE_ONCE(ep->sync_source->sync_sink, NULL); + stop_urbs(ep, false); ++ } + } + + /** diff --git a/queue-5.12/asoc-ak4458-add-module_device_table.patch b/queue-5.12/asoc-ak4458-add-module_device_table.patch new file mode 100644 index 00000000000..c7642f1b00b --- /dev/null +++ b/queue-5.12/asoc-ak4458-add-module_device_table.patch @@ -0,0 +1,32 @@ +From f84b4524005238fc9fd5cf615bb426fa40a99494 Mon Sep 17 00:00:00 2001 +From: Shengjiu Wang +Date: Wed, 24 Feb 2021 14:57:51 +0800 +Subject: ASoC: ak4458: Add MODULE_DEVICE_TABLE + +From: Shengjiu Wang + +commit f84b4524005238fc9fd5cf615bb426fa40a99494 upstream. + +Add missed MODULE_DEVICE_TABLE for the driver can be loaded +automatically at boot. + +Fixes: 08660086eff9 ("ASoC: ak4458: Add support for AK4458 DAC driver") +Cc: +Signed-off-by: Shengjiu Wang +Link: https://lore.kernel.org/r/1614149872-25510-1-git-send-email-shengjiu.wang@nxp.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/ak4458.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/soc/codecs/ak4458.c ++++ b/sound/soc/codecs/ak4458.c +@@ -823,6 +823,7 @@ static struct i2c_driver ak4458_i2c_driv + .probe_new = ak4458_i2c_probe, + .remove = ak4458_i2c_remove, + }; ++MODULE_DEVICE_TABLE(of, ak4458_of_match); + + module_i2c_driver(ak4458_i2c_driver); + diff --git a/queue-5.12/asoc-ak5558-add-module_device_table.patch b/queue-5.12/asoc-ak5558-add-module_device_table.patch new file mode 100644 index 00000000000..bdb9c74facd --- /dev/null +++ b/queue-5.12/asoc-ak5558-add-module_device_table.patch @@ -0,0 +1,32 @@ +From 741c8397e5d0b339fb3e614a9ff5cb4bf7ae1a65 Mon Sep 17 00:00:00 2001 +From: Shengjiu Wang +Date: Wed, 24 Feb 2021 14:57:52 +0800 +Subject: ASoC: ak5558: Add MODULE_DEVICE_TABLE + +From: Shengjiu Wang + +commit 741c8397e5d0b339fb3e614a9ff5cb4bf7ae1a65 upstream. + +Add missed MODULE_DEVICE_TABLE for the driver can be loaded +automatically at boot. + +Fixes: 920884777480 ("ASoC: ak5558: Add support for AK5558 ADC driver") +Cc: +Signed-off-by: Shengjiu Wang +Link: https://lore.kernel.org/r/1614149872-25510-2-git-send-email-shengjiu.wang@nxp.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/ak5558.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/soc/codecs/ak5558.c ++++ b/sound/soc/codecs/ak5558.c +@@ -430,6 +430,7 @@ static struct i2c_driver ak5558_i2c_driv + .probe_new = ak5558_i2c_probe, + .remove = ak5558_i2c_remove, + }; ++MODULE_DEVICE_TABLE(of, ak5558_i2c_dt_ids); + + module_i2c_driver(ak5558_i2c_driver); + diff --git a/queue-5.12/ovl-allow-upperdir-inside-lowerdir.patch b/queue-5.12/ovl-allow-upperdir-inside-lowerdir.patch new file mode 100644 index 00000000000..a8b82b03427 --- /dev/null +++ b/queue-5.12/ovl-allow-upperdir-inside-lowerdir.patch @@ -0,0 +1,82 @@ +From 708fa01597fa002599756bf56a96d0de1677375c Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Mon, 12 Apr 2021 12:00:37 +0200 +Subject: ovl: allow upperdir inside lowerdir + +From: Miklos Szeredi + +commit 708fa01597fa002599756bf56a96d0de1677375c upstream. + +Commit 146d62e5a586 ("ovl: detect overlapping layers") made sure we don't +have overlapping layers, but it also broke the arguably valid use case of + + mount -olowerdir=/,upperdir=/subdir,.. + +where upperdir overlaps lowerdir on the same filesystem. This has been +causing regressions. + +Revert the check, but only for the specific case where upperdir and/or +workdir are subdirectories of lowerdir. Any other overlap (e.g. lowerdir +is subdirectory of upperdir, etc) case is crazy, so leave the check in +place for those. + +Overlaps are detected at lookup time too, so reverting the mount time check +should be safe. + +Fixes: 146d62e5a586 ("ovl: detect overlapping layers") +Cc: # v5.2 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman +--- + fs/overlayfs/super.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +--- a/fs/overlayfs/super.c ++++ b/fs/overlayfs/super.c +@@ -1826,7 +1826,8 @@ out_err: + * - upper/work dir of any overlayfs instance + */ + static int ovl_check_layer(struct super_block *sb, struct ovl_fs *ofs, +- struct dentry *dentry, const char *name) ++ struct dentry *dentry, const char *name, ++ bool is_lower) + { + struct dentry *next = dentry, *parent; + int err = 0; +@@ -1838,7 +1839,7 @@ static int ovl_check_layer(struct super_ + + /* Walk back ancestors to root (inclusive) looking for traps */ + while (!err && parent != next) { +- if (ovl_lookup_trap_inode(sb, parent)) { ++ if (is_lower && ovl_lookup_trap_inode(sb, parent)) { + err = -ELOOP; + pr_err("overlapping %s path\n", name); + } else if (ovl_is_inuse(parent)) { +@@ -1864,7 +1865,7 @@ static int ovl_check_overlapping_layers( + + if (ovl_upper_mnt(ofs)) { + err = ovl_check_layer(sb, ofs, ovl_upper_mnt(ofs)->mnt_root, +- "upperdir"); ++ "upperdir", false); + if (err) + return err; + +@@ -1875,7 +1876,8 @@ static int ovl_check_overlapping_layers( + * workbasedir. In that case, we already have their traps in + * inode cache and we will catch that case on lookup. + */ +- err = ovl_check_layer(sb, ofs, ofs->workbasedir, "workdir"); ++ err = ovl_check_layer(sb, ofs, ofs->workbasedir, "workdir", ++ false); + if (err) + return err; + } +@@ -1883,7 +1885,7 @@ static int ovl_check_overlapping_layers( + for (i = 1; i < ofs->numlayer; i++) { + err = ovl_check_layer(sb, ofs, + ofs->layers[i].mnt->mnt_root, +- "lowerdir"); ++ "lowerdir", true); + if (err) + return err; + } diff --git a/queue-5.12/ovl-fix-leaked-dentry.patch b/queue-5.12/ovl-fix-leaked-dentry.patch new file mode 100644 index 00000000000..624d3abd91b --- /dev/null +++ b/queue-5.12/ovl-fix-leaked-dentry.patch @@ -0,0 +1,79 @@ +From eaab1d45cdb4bb0c846bd23c3d666d5b90af7b41 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= +Date: Mon, 29 Mar 2021 18:49:07 +0200 +Subject: ovl: fix leaked dentry +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mickaël Salaün + +commit eaab1d45cdb4bb0c846bd23c3d666d5b90af7b41 upstream. + +Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in +ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a +metacopy error, which leads to dentry leaks when shutting down the related +superblock: + + overlayfs: refusing to follow metacopy origin for (/file0) + ... + BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] + ... + WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d + CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 + ... + RIP: 0010:umount_check.cold+0x107/0x14d + ... + Call Trace: + d_walk+0x28c/0x950 + ? dentry_lru_isolate+0x2b0/0x2b0 + ? __kasan_slab_free+0x12/0x20 + do_one_tree+0x33/0x60 + shrink_dcache_for_umount+0x78/0x1d0 + generic_shutdown_super+0x70/0x440 + kill_anon_super+0x3e/0x70 + deactivate_locked_super+0xc4/0x160 + deactivate_super+0xfa/0x140 + cleanup_mnt+0x22e/0x370 + __cleanup_mnt+0x1a/0x30 + task_work_run+0x139/0x210 + do_exit+0xb0c/0x2820 + ? __kasan_check_read+0x1d/0x30 + ? find_held_lock+0x35/0x160 + ? lock_release+0x1b6/0x660 + ? mm_update_next_owner+0xa20/0xa20 + ? reacquire_held_locks+0x3f0/0x3f0 + ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 + do_group_exit+0x135/0x380 + __do_sys_exit_group.isra.0+0x20/0x20 + __x64_sys_exit_group+0x3c/0x50 + do_syscall_64+0x45/0x70 + entry_SYSCALL_64_after_hwframe+0x44/0xae + ... + VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day... + +This fix has been tested with a syzkaller reproducer. + +Cc: Amir Goldstein +Cc: # v5.8+ +Reported-by: syzbot +Fixes: 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()") +Signed-off-by: Mickaël Salaün +Link: https://lore.kernel.org/r/20210329164907.2133175-1-mic@digikod.net +Reviewed-by: Vivek Goyal +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman +--- + fs/overlayfs/namei.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/overlayfs/namei.c ++++ b/fs/overlayfs/namei.c +@@ -919,6 +919,7 @@ struct dentry *ovl_lookup(struct inode * + continue; + + if ((uppermetacopy || d.metacopy) && !ofs->config.metacopy) { ++ dput(this); + err = -EPERM; + pr_warn_ratelimited("refusing to follow metacopy origin for (%pd2)\n", dentry); + goto out_put; diff --git a/queue-5.12/platform-x86-thinkpad_acpi-correct-thermal-sensor-allocation.patch b/queue-5.12/platform-x86-thinkpad_acpi-correct-thermal-sensor-allocation.patch new file mode 100644 index 00000000000..cf29b9f76d2 --- /dev/null +++ b/queue-5.12/platform-x86-thinkpad_acpi-correct-thermal-sensor-allocation.patch @@ -0,0 +1,102 @@ +From 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 Mon Sep 17 00:00:00 2001 +From: Mark Pearson +Date: Wed, 7 Apr 2021 17:20:15 -0400 +Subject: platform/x86: thinkpad_acpi: Correct thermal sensor allocation + +From: Mark Pearson + +commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream. + +On recent Thinkpad platforms it was reported that temp sensor 11 was +always incorrectly displaying 66C. It turns out the reason for this is +that this location in EC RAM is not a temperature sensor but is the +power supply ID (offset 0xC2). + +Based on feedback from the Lenovo firmware team the EC RAM version can +be determined and for the current version (3) only the 0x78 to 0x7F +range is used for temp sensors. I don't have any details for earlier +versions so I have left the implementation unaltered there. + +Note - in this block only 0x78 and 0x79 are officially designated (CPU & +GPU sensors). The use of the other locations in the block will vary from +platform to platform; but the existing logic to detect a sensor presence +holds. + +Signed-off-by: Mark Pearson +Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com +Reviewed-by: Hans de Goede +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/thinkpad_acpi.c | 31 ++++++++++++++++++++++--------- + 1 file changed, 22 insertions(+), 9 deletions(-) + +--- a/drivers/platform/x86/thinkpad_acpi.c ++++ b/drivers/platform/x86/thinkpad_acpi.c +@@ -6260,6 +6260,7 @@ enum thermal_access_mode { + enum { /* TPACPI_THERMAL_TPEC_* */ + TP_EC_THERMAL_TMP0 = 0x78, /* ACPI EC regs TMP 0..7 */ + TP_EC_THERMAL_TMP8 = 0xC0, /* ACPI EC regs TMP 8..15 */ ++ TP_EC_FUNCREV = 0xEF, /* ACPI EC Functional revision */ + TP_EC_THERMAL_TMP_NA = -128, /* ACPI EC sensor not available */ + + TPACPI_THERMAL_SENSOR_NA = -128000, /* Sensor not available */ +@@ -6458,7 +6459,7 @@ static const struct attribute_group ther + + static int __init thermal_init(struct ibm_init_struct *iibm) + { +- u8 t, ta1, ta2; ++ u8 t, ta1, ta2, ver = 0; + int i; + int acpi_tmp7; + int res; +@@ -6473,7 +6474,14 @@ static int __init thermal_init(struct ib + * 0x78-0x7F, 0xC0-0xC7. Registers return 0x00 for + * non-implemented, thermal sensors return 0x80 when + * not available ++ * The above rule is unfortunately flawed. This has been seen with ++ * 0xC2 (power supply ID) causing thermal control problems. ++ * The EC version can be determined by offset 0xEF and at least for ++ * version 3 the Lenovo firmware team confirmed that registers 0xC0-0xC7 ++ * are not thermal registers. + */ ++ if (!acpi_ec_read(TP_EC_FUNCREV, &ver)) ++ pr_warn("Thinkpad ACPI EC unable to access EC version\n"); + + ta1 = ta2 = 0; + for (i = 0; i < 8; i++) { +@@ -6483,11 +6491,13 @@ static int __init thermal_init(struct ib + ta1 = 0; + break; + } +- if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, &t)) { +- ta2 |= t; +- } else { +- ta1 = 0; +- break; ++ if (ver < 3) { ++ if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, &t)) { ++ ta2 |= t; ++ } else { ++ ta1 = 0; ++ break; ++ } + } + } + if (ta1 == 0) { +@@ -6500,9 +6510,12 @@ static int __init thermal_init(struct ib + thermal_read_mode = TPACPI_THERMAL_NONE; + } + } else { +- thermal_read_mode = +- (ta2 != 0) ? +- TPACPI_THERMAL_TPEC_16 : TPACPI_THERMAL_TPEC_8; ++ if (ver >= 3) ++ thermal_read_mode = TPACPI_THERMAL_TPEC_8; ++ else ++ thermal_read_mode = ++ (ta2 != 0) ? ++ TPACPI_THERMAL_TPEC_16 : TPACPI_THERMAL_TPEC_8; + } + } else if (acpi_tmp7) { + if (tpacpi_is_ibm() && diff --git a/queue-5.12/series b/queue-5.12/series index 086b3245711..8ac3534e709 100644 --- a/queue-5.12/series +++ b/queue-5.12/series @@ -5,3 +5,12 @@ drm-i915-disable-runtime-power-management-during-shutdown.patch bpf-fix-masking-negation-logic-upon-negative-dst-register.patch bpf-fix-leakage-of-uninitialized-bpf-stack-under-speculation.patch net-qrtr-avoid-potential-use-after-free-in-mhi-send.patch +ovl-fix-leaked-dentry.patch +ovl-allow-upperdir-inside-lowerdir.patch +alsa-usb-audio-add-midi-quirk-for-vox-tonelab-ex.patch +alsa-usb-audio-fix-implicit-sync-clearance-at-stopping-stream.patch +usb-add-lpm-quirk-for-lenovo-thinkpad-usb-c-dock-gen2-ethernet.patch +usb-add-reset-resume-quirk-for-wd19-s-realtek-hub.patch +asoc-ak4458-add-module_device_table.patch +asoc-ak5558-add-module_device_table.patch +platform-x86-thinkpad_acpi-correct-thermal-sensor-allocation.patch diff --git a/queue-5.12/usb-add-lpm-quirk-for-lenovo-thinkpad-usb-c-dock-gen2-ethernet.patch b/queue-5.12/usb-add-lpm-quirk-for-lenovo-thinkpad-usb-c-dock-gen2-ethernet.patch new file mode 100644 index 00000000000..ddf22b9f4c8 --- /dev/null +++ b/queue-5.12/usb-add-lpm-quirk-for-lenovo-thinkpad-usb-c-dock-gen2-ethernet.patch @@ -0,0 +1,36 @@ +From 8f23fe35ff1e5491b4d279323a8209a31f03ae65 Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Mon, 12 Apr 2021 21:54:53 +0800 +Subject: USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet + +From: Kai-Heng Feng + +commit 8f23fe35ff1e5491b4d279323a8209a31f03ae65 upstream. + +This is another branded 8153 device that doesn't work well with LPM +enabled: +[ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status -71 + +So disable LPM to resolve the issue. + +Signed-off-by: Kai-Heng Feng +BugLink: https://bugs.launchpad.net/bugs/1922651 +Link: https://lore.kernel.org/r/20210412135455.791971-1-kai.heng.feng@canonical.com +Cc: stable +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 +@@ -438,6 +438,9 @@ static const struct usb_device_id usb_qu + { USB_DEVICE(0x17ef, 0xa012), .driver_info = + USB_QUIRK_DISCONNECT_SUSPEND }, + ++ /* Lenovo ThinkPad USB-C Dock Gen2 Ethernet (RTL8153 GigE) */ ++ { USB_DEVICE(0x17ef, 0xa387), .driver_info = USB_QUIRK_NO_LPM }, ++ + /* BUILDWIN Photo Frame */ + { USB_DEVICE(0x1908, 0x1315), .driver_info = + USB_QUIRK_HONOR_BNUMINTERFACES }, diff --git a/queue-5.12/usb-add-reset-resume-quirk-for-wd19-s-realtek-hub.patch b/queue-5.12/usb-add-reset-resume-quirk-for-wd19-s-realtek-hub.patch new file mode 100644 index 00000000000..56c0cbbfbc5 --- /dev/null +++ b/queue-5.12/usb-add-reset-resume-quirk-for-wd19-s-realtek-hub.patch @@ -0,0 +1,55 @@ +From ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a Mon Sep 17 00:00:00 2001 +From: Chris Chiu +Date: Wed, 21 Apr 2021 01:46:51 +0800 +Subject: USB: Add reset-resume quirk for WD19's Realtek Hub + +From: Chris Chiu + +commit ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a upstream. + +Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work +after the system resumes from suspend with remote wakeup enabled +device connected: +[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) +[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71) +[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71) +[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71) + +Information of this hub: +T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 5 +D: Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 +P: Vendor=0bda ProdID=5487 Rev= 1.47 +S: Manufacturer=Dell Inc. +S: Product=Dell dock +C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA +I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub +E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms +I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub +E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms + +The failure results from the ETIMEDOUT by chance when turning on +the suspend feature for the specified port of the hub. The port +seems to be in an unknown state so the hub_activate during resume +fails the hub_port_status, then the hub will fail to work. + +The quirky hub needs the reset-resume quirk to function correctly. + +Acked-by: Alan Stern +Signed-off-by: Chris Chiu +Cc: stable +Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -406,6 +406,7 @@ 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 }, ++ { USB_DEVICE(0x0bda, 0x5487), .driver_info = USB_QUIRK_RESET_RESUME }, + + /* Generic RTL8153 based ethernet adapters */ + { USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },