From: Greg Kroah-Hartman Date: Mon, 26 Jul 2021 08:13:35 +0000 (+0200) Subject: 5.13-stable patches X-Git-Tag: v4.4.277~70 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=5deda6ca4bdbe987dd84f5525a8f9eb8821218f8;p=thirdparty%2Fkernel%2Fstable-queue.git 5.13-stable patches added patches: alsa-hda-realtek-fix-pop-noise-and-2-front-mic-issues-on-a-machine.patch alsa-hdmi-expose-all-pins-on-msi-ms-7c94-board.patch alsa-pcm-call-substream-ack-method-upon-compat-mmap-commit.patch alsa-pcm-fix-mmap-capability-check.patch alsa-sb-fix-potential-abba-deadlock-in-csp-driver.patch alsa-usb-audio-add-missing-proc-text-entry-for-bespoken-type.patch alsa-usb-audio-add-registration-quirk-for-jbl-quantum-headsets.patch io_uring-fix-race-condition-when-sqp-thread-goes-to-sleep.patch mmc-core-don-t-allocate-ida-for-of-aliases.patch revert-usb-renesas-xhci-fix-handling-of-unknown-rom-state.patch s390-boot-fix-use-of-expolines-in-the-dma-code.patch s390-ftrace-fix-ftrace_update_ftrace_func-implementation.patch usb-ehci-prevent-missed-ehci-interrupts-with-edge-triggered-msi.patch usb-xhci-avoid-renesas_usb_fw.mem-when-it-s-unusable.patch xhci-fix-lost-usb-2-remote-wake.patch --- diff --git a/queue-5.13/alsa-hda-realtek-fix-pop-noise-and-2-front-mic-issues-on-a-machine.patch b/queue-5.13/alsa-hda-realtek-fix-pop-noise-and-2-front-mic-issues-on-a-machine.patch new file mode 100644 index 00000000000..841a5ce48b9 --- /dev/null +++ b/queue-5.13/alsa-hda-realtek-fix-pop-noise-and-2-front-mic-issues-on-a-machine.patch @@ -0,0 +1,35 @@ +From e4efa82660e6d80338c554e45e903714e1b2c27b Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Mon, 19 Jul 2021 11:02:31 +0800 +Subject: ALSA: hda/realtek: Fix pop noise and 2 Front Mic issues on a machine + +From: Hui Wang + +commit e4efa82660e6d80338c554e45e903714e1b2c27b upstream. + +This is a Lenovo ThinkStation machine which uses the codec alc623. +There are 2 issues on this machine, the 1st one is the pop noise in +the lineout, the 2nd one is there are 2 Front Mics and pulseaudio +can't handle them, After applying the fixup of +ALC623_FIXUP_LENOVO_THINKSTATION_P340 to this machine, the 2 issues +are fixed. + +Cc: +Signed-off-by: Hui Wang +Link: https://lore.kernel.org/r/20210719030231.6870-1-hui.wang@canonical.com +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 +@@ -8566,6 +8566,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x17aa, 0x3151, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x17aa, 0x3176, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x17aa, 0x3178, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), ++ SND_PCI_QUIRK(0x17aa, 0x31af, "ThinkCentre Station", ALC623_FIXUP_LENOVO_THINKSTATION_P340), + SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940", ALC298_FIXUP_LENOVO_SPK_VOLUME), + SND_PCI_QUIRK(0x17aa, 0x3827, "Ideapad S740", ALC285_FIXUP_IDEAPAD_S740_COEF), + SND_PCI_QUIRK(0x17aa, 0x3843, "Yoga 9i", ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP), diff --git a/queue-5.13/alsa-hdmi-expose-all-pins-on-msi-ms-7c94-board.patch b/queue-5.13/alsa-hdmi-expose-all-pins-on-msi-ms-7c94-board.patch new file mode 100644 index 00000000000..3feb7476688 --- /dev/null +++ b/queue-5.13/alsa-hdmi-expose-all-pins-on-msi-ms-7c94-board.patch @@ -0,0 +1,35 @@ +From 33f735f137c6539e3ceceb515cd1e2a644005b49 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 16 Jul 2021 15:56:00 +0200 +Subject: ALSA: hdmi: Expose all pins on MSI MS-7C94 board + +From: Takashi Iwai + +commit 33f735f137c6539e3ceceb515cd1e2a644005b49 upstream. + +The BIOS on MSI Mortar B550m WiFi (MS-7C94) board with AMDGPU seems +disabling the other pins than HDMI although it has more outputs +including DP. + +This patch adds the board to the allow list for enabling all pins. + +Reported-by: Damjan Georgievski +Cc: +Link: https://lore.kernel.org/r/CAEk1YH4Jd0a8vfZxORVu7qg+Zsc-K+pR187ezNq8QhJBPW4gpw@mail.gmail.com +Link: https://lore.kernel.org/r/20210716135600.24176-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_hdmi.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_hdmi.c ++++ b/sound/pci/hda/patch_hdmi.c +@@ -1940,6 +1940,7 @@ static int hdmi_add_cvt(struct hda_codec + static const struct snd_pci_quirk force_connect_list[] = { + SND_PCI_QUIRK(0x103c, 0x870f, "HP", 1), + SND_PCI_QUIRK(0x103c, 0x871a, "HP", 1), ++ SND_PCI_QUIRK(0x1462, 0xec94, "MS-7C94", 1), + {} + }; + diff --git a/queue-5.13/alsa-pcm-call-substream-ack-method-upon-compat-mmap-commit.patch b/queue-5.13/alsa-pcm-call-substream-ack-method-upon-compat-mmap-commit.patch new file mode 100644 index 00000000000..38de9b8d372 --- /dev/null +++ b/queue-5.13/alsa-pcm-call-substream-ack-method-upon-compat-mmap-commit.patch @@ -0,0 +1,48 @@ +From 2e2832562c877e6530b8480982d99a4ff90c6777 Mon Sep 17 00:00:00 2001 +From: Alan Young +Date: Fri, 9 Jul 2021 09:48:54 +0100 +Subject: ALSA: pcm: Call substream ack() method upon compat mmap commit + +From: Alan Young + +commit 2e2832562c877e6530b8480982d99a4ff90c6777 upstream. + +If a 32-bit application is being used with a 64-bit kernel and is using +the mmap mechanism to write data, then the SNDRV_PCM_IOCTL_SYNC_PTR +ioctl results in calling snd_pcm_ioctl_sync_ptr_compat(). Make this use +pcm_lib_apply_appl_ptr() so that the substream's ack() method, if +defined, is called. + +The snd_pcm_sync_ptr() function, used in the 64-bit ioctl case, already +uses snd_pcm_ioctl_sync_ptr_compat(). + +Fixes: 9027c4639ef1 ("ALSA: pcm: Call ack() whenever appl_ptr is updated") +Signed-off-by: Alan Young +Cc: +Link: https://lore.kernel.org/r/c441f18c-eb2a-3bdd-299a-696ccca2de9c@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/core/pcm_native.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/sound/core/pcm_native.c ++++ b/sound/core/pcm_native.c +@@ -3057,9 +3057,14 @@ static int snd_pcm_ioctl_sync_ptr_compat + boundary = 0x7fffffff; + snd_pcm_stream_lock_irq(substream); + /* FIXME: we should consider the boundary for the sync from app */ +- if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) +- control->appl_ptr = scontrol.appl_ptr; +- else ++ if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) { ++ err = pcm_lib_apply_appl_ptr(substream, ++ scontrol.appl_ptr); ++ if (err < 0) { ++ snd_pcm_stream_unlock_irq(substream); ++ return err; ++ } ++ } else + scontrol.appl_ptr = control->appl_ptr % boundary; + if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN)) + control->avail_min = scontrol.avail_min; diff --git a/queue-5.13/alsa-pcm-fix-mmap-capability-check.patch b/queue-5.13/alsa-pcm-fix-mmap-capability-check.patch new file mode 100644 index 00000000000..4bebfc63dd0 --- /dev/null +++ b/queue-5.13/alsa-pcm-fix-mmap-capability-check.patch @@ -0,0 +1,46 @@ +From c4824ae7db418aee6f50f308a20b832e58e997fd Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 20 Jul 2021 11:26:40 +0200 +Subject: ALSA: pcm: Fix mmap capability check + +From: Takashi Iwai + +commit c4824ae7db418aee6f50f308a20b832e58e997fd upstream. + +The hw_support_mmap() doesn't cover all memory allocation types and +might use a wrong device pointer for checking the capability. +Check the all memory allocation types more completely. + +Cc: +Link: https://lore.kernel.org/r/20210720092640.12338-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/core/pcm_native.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +--- a/sound/core/pcm_native.c ++++ b/sound/core/pcm_native.c +@@ -246,12 +246,18 @@ static bool hw_support_mmap(struct snd_p + if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP)) + return false; + +- if (substream->ops->mmap || +- (substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV && +- substream->dma_buffer.dev.type != SNDRV_DMA_TYPE_DEV_UC)) ++ if (substream->ops->mmap) + return true; + +- return dma_can_mmap(substream->dma_buffer.dev.dev); ++ switch (substream->dma_buffer.dev.type) { ++ case SNDRV_DMA_TYPE_UNKNOWN: ++ return false; ++ case SNDRV_DMA_TYPE_CONTINUOUS: ++ case SNDRV_DMA_TYPE_VMALLOC: ++ return true; ++ default: ++ return dma_can_mmap(substream->dma_buffer.dev.dev); ++ } + } + + static int constrain_mask_params(struct snd_pcm_substream *substream, diff --git a/queue-5.13/alsa-sb-fix-potential-abba-deadlock-in-csp-driver.patch b/queue-5.13/alsa-sb-fix-potential-abba-deadlock-in-csp-driver.patch new file mode 100644 index 00000000000..1283ce68290 --- /dev/null +++ b/queue-5.13/alsa-sb-fix-potential-abba-deadlock-in-csp-driver.patch @@ -0,0 +1,75 @@ +From 1c2b9519159b470ef24b2638f4794e86e2952ab7 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 16 Jul 2021 15:27:23 +0200 +Subject: ALSA: sb: Fix potential ABBA deadlock in CSP driver + +From: Takashi Iwai + +commit 1c2b9519159b470ef24b2638f4794e86e2952ab7 upstream. + +SB16 CSP driver may hit potentially a typical ABBA deadlock in two +code paths: + + In snd_sb_csp_stop(): + spin_lock_irqsave(&p->chip->mixer_lock, flags); + spin_lock(&p->chip->reg_lock); + + In snd_sb_csp_load(): + spin_lock_irqsave(&p->chip->reg_lock, flags); + spin_lock(&p->chip->mixer_lock); + +Also the similar pattern is seen in snd_sb_csp_start(). + +Although the practical impact is very small (those states aren't +triggered in the same running state and this happens only on a real +hardware, decades old ISA sound boards -- which must be very difficult +to find nowadays), it's a real scenario and has to be fixed. + +This patch addresses those deadlocks by splitting the locks in +snd_sb_csp_start() and snd_sb_csp_stop() for avoiding the nested +locks. + +Reported-by: Jia-Ju Bai +Cc: +Link: https://lore.kernel.org/r/7b0fcdaf-cd4f-4728-2eae-48c151a92e10@gmail.com +Link: https://lore.kernel.org/r/20210716132723.13216-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/isa/sb/sb16_csp.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/sound/isa/sb/sb16_csp.c ++++ b/sound/isa/sb/sb16_csp.c +@@ -814,6 +814,7 @@ static int snd_sb_csp_start(struct snd_s + mixR = snd_sbmixer_read(p->chip, SB_DSP4_PCM_DEV + 1); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV, mixL & 0x7); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV + 1, mixR & 0x7); ++ spin_unlock_irqrestore(&p->chip->mixer_lock, flags); + + spin_lock(&p->chip->reg_lock); + set_mode_register(p->chip, 0xc0); /* c0 = STOP */ +@@ -853,6 +854,7 @@ static int snd_sb_csp_start(struct snd_s + spin_unlock(&p->chip->reg_lock); + + /* restore PCM volume */ ++ spin_lock_irqsave(&p->chip->mixer_lock, flags); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV, mixL); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV + 1, mixR); + spin_unlock_irqrestore(&p->chip->mixer_lock, flags); +@@ -878,6 +880,7 @@ static int snd_sb_csp_stop(struct snd_sb + mixR = snd_sbmixer_read(p->chip, SB_DSP4_PCM_DEV + 1); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV, mixL & 0x7); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV + 1, mixR & 0x7); ++ spin_unlock_irqrestore(&p->chip->mixer_lock, flags); + + spin_lock(&p->chip->reg_lock); + if (p->running & SNDRV_SB_CSP_ST_QSOUND) { +@@ -892,6 +895,7 @@ static int snd_sb_csp_stop(struct snd_sb + spin_unlock(&p->chip->reg_lock); + + /* restore PCM volume */ ++ spin_lock_irqsave(&p->chip->mixer_lock, flags); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV, mixL); + snd_sbmixer_write(p->chip, SB_DSP4_PCM_DEV + 1, mixR); + spin_unlock_irqrestore(&p->chip->mixer_lock, flags); diff --git a/queue-5.13/alsa-usb-audio-add-missing-proc-text-entry-for-bespoken-type.patch b/queue-5.13/alsa-usb-audio-add-missing-proc-text-entry-for-bespoken-type.patch new file mode 100644 index 00000000000..17e7c2567f4 --- /dev/null +++ b/queue-5.13/alsa-usb-audio-add-missing-proc-text-entry-for-bespoken-type.patch @@ -0,0 +1,45 @@ +From 64752a95b702817602d72f109ceaf5ec0780e283 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 14 Jul 2021 10:48:36 +0200 +Subject: ALSA: usb-audio: Add missing proc text entry for BESPOKEN type + +From: Takashi Iwai + +commit 64752a95b702817602d72f109ceaf5ec0780e283 upstream. + +Recently we've added a new usb_mixer element type, USB_MIXER_BESPOKEN, +but it wasn't added in the table in snd_usb_mixer_dump_cval(). This +is no big problem since each bespoken type should have its own dump +method, but it still isn't disallowed to use the standard one, so we +should cover it as well. Along with it, define the table with the +explicit array initializer for avoiding other pitfalls. + +Fixes: 785b6f29a795 ("ALSA: usb-audio: scarlett2: Fix wrong resume call") +Reported-by: Pavel Machek +Cc: +Link: https://lore.kernel.org/r/20210714084836.1977-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/mixer.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/sound/usb/mixer.c ++++ b/sound/usb/mixer.c +@@ -3295,7 +3295,15 @@ static void snd_usb_mixer_dump_cval(stru + { + struct usb_mixer_elem_info *cval = mixer_elem_list_to_info(list); + static const char * const val_types[] = { +- "BOOLEAN", "INV_BOOLEAN", "S8", "U8", "S16", "U16", "S32", "U32", ++ [USB_MIXER_BOOLEAN] = "BOOLEAN", ++ [USB_MIXER_INV_BOOLEAN] = "INV_BOOLEAN", ++ [USB_MIXER_S8] = "S8", ++ [USB_MIXER_U8] = "U8", ++ [USB_MIXER_S16] = "S16", ++ [USB_MIXER_U16] = "U16", ++ [USB_MIXER_S32] = "S32", ++ [USB_MIXER_U32] = "U32", ++ [USB_MIXER_BESPOKEN] = "BESPOKEN", + }; + snd_iprintf(buffer, " Info: id=%i, control=%i, cmask=0x%x, " + "channels=%i, type=\"%s\"\n", cval->head.id, diff --git a/queue-5.13/alsa-usb-audio-add-registration-quirk-for-jbl-quantum-headsets.patch b/queue-5.13/alsa-usb-audio-add-registration-quirk-for-jbl-quantum-headsets.patch new file mode 100644 index 00000000000..475a5722d2e --- /dev/null +++ b/queue-5.13/alsa-usb-audio-add-registration-quirk-for-jbl-quantum-headsets.patch @@ -0,0 +1,38 @@ +From b0084afde27fe8a504377dee65f55bc6aa776937 Mon Sep 17 00:00:00 2001 +From: Alexander Tsoy +Date: Thu, 22 Jul 2021 02:56:05 +0300 +Subject: ALSA: usb-audio: Add registration quirk for JBL Quantum headsets +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alexander Tsoy + +commit b0084afde27fe8a504377dee65f55bc6aa776937 upstream. + +These devices has two interfaces, but only the second interface +contains the capture endpoint, thus quirk is required to delay the +registration until the second interface appears. + +Tested-by: Jakub Fišer +Signed-off-by: Alexander Tsoy +Cc: +Link: https://lore.kernel.org/r/20210721235605.53741-1-alexander@tsoy.me +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1897,6 +1897,9 @@ static const struct registration_quirk r + REG_QUIRK_ENTRY(0x0951, 0x16d8, 2), /* Kingston HyperX AMP */ + REG_QUIRK_ENTRY(0x0951, 0x16ed, 2), /* Kingston HyperX Cloud Alpha S */ + REG_QUIRK_ENTRY(0x0951, 0x16ea, 2), /* Kingston HyperX Cloud Flight S */ ++ REG_QUIRK_ENTRY(0x0ecb, 0x1f46, 2), /* JBL Quantum 600 */ ++ REG_QUIRK_ENTRY(0x0ecb, 0x2039, 2), /* JBL Quantum 400 */ ++ REG_QUIRK_ENTRY(0x0ecb, 0x203e, 2), /* JBL Quantum 800 */ + { 0 } /* terminator */ + }; + diff --git a/queue-5.13/io_uring-fix-race-condition-when-sqp-thread-goes-to-sleep.patch b/queue-5.13/io_uring-fix-race-condition-when-sqp-thread-goes-to-sleep.patch new file mode 100644 index 00000000000..854fc676fbf --- /dev/null +++ b/queue-5.13/io_uring-fix-race-condition-when-sqp-thread-goes-to-sleep.patch @@ -0,0 +1,35 @@ +From 997135017716c33f3405e86cca5da9567b40a08e Mon Sep 17 00:00:00 2001 +From: Olivier Langlois +Date: Wed, 23 Jun 2021 11:50:11 -0700 +Subject: io_uring: Fix race condition when sqp thread goes to sleep + +From: Olivier Langlois + +commit 997135017716c33f3405e86cca5da9567b40a08e upstream. + +If an asynchronous completion happens before the task is preparing +itself to wait and set its state to TASK_INTERRUPTIBLE, the completion +will not wake up the sqp thread. + +Cc: stable@vger.kernel.org +Signed-off-by: Olivier Langlois +Reviewed-by: Pavel Begunkov +Link: https://lore.kernel.org/r/d1419dc32ec6a97b453bee34dc03fa6a02797142.1624473200.git.olivier@trillion01.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + fs/io_uring.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -6876,7 +6876,8 @@ static int io_sq_thread(void *data) + } + + prepare_to_wait(&sqd->wait, &wait, TASK_INTERRUPTIBLE); +- if (!test_bit(IO_SQ_THREAD_SHOULD_PARK, &sqd->state)) { ++ if (!test_bit(IO_SQ_THREAD_SHOULD_PARK, &sqd->state) && ++ !io_run_task_work()) { + list_for_each_entry(ctx, &sqd->ctx_list, sqd_list) + io_ring_set_wakeup_flag(ctx); + diff --git a/queue-5.13/mmc-core-don-t-allocate-ida-for-of-aliases.patch b/queue-5.13/mmc-core-don-t-allocate-ida-for-of-aliases.patch new file mode 100644 index 00000000000..f0a011f98ea --- /dev/null +++ b/queue-5.13/mmc-core-don-t-allocate-ida-for-of-aliases.patch @@ -0,0 +1,94 @@ +From 10252bae863d09b9648bed2e035572d207200ca1 Mon Sep 17 00:00:00 2001 +From: Stephen Boyd +Date: Wed, 23 Jun 2021 00:50:02 -0700 +Subject: mmc: core: Don't allocate IDA for OF aliases + +From: Stephen Boyd + +commit 10252bae863d09b9648bed2e035572d207200ca1 upstream. + +There's a chance that the IDA allocated in mmc_alloc_host() is not freed +for some time because it's freed as part of a class' release function +(see mmc_host_classdev_release() where the IDA is freed). If another +thread is holding a reference to the class, then only once all balancing +device_put() calls (in turn calling kobject_put()) have been made will +the IDA be released and usable again. + +Normally this isn't a problem because the kobject is released before +anything else that may want to use the same number tries to again, but +with CONFIG_DEBUG_KOBJECT_RELEASE=y and OF aliases it becomes pretty +easy to try to allocate an alias from the IDA twice while the first time +it was allocated is still pending a call to ida_simple_remove(). It's +also possible to trigger it by using CONFIG_DEBUG_KOBJECT_RELEASE and +probe defering a driver at boot that calls mmc_alloc_host() before +trying to get resources that may defer likes clks or regulators. + +Instead of allocating from the IDA in this scenario, let's just skip it +if we know this is an OF alias. The number is already "claimed" and +devices that aren't using OF aliases won't try to use the claimed +numbers anyway (see mmc_first_nonreserved_index()). This should avoid +any issues with mmc_alloc_host() returning failures from the +ida_simple_get() in the case that we're using an OF alias. + +Cc: Matthias Schiffer +Cc: Sujit Kautkar +Reported-by: Zubin Mithra +Fixes: fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") +Signed-off-by: Stephen Boyd +Link: https://lore.kernel.org/r/20210623075002.1746924-3-swboyd@chromium.org +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/host.c | 20 ++++++++++---------- + 1 file changed, 10 insertions(+), 10 deletions(-) + +--- a/drivers/mmc/core/host.c ++++ b/drivers/mmc/core/host.c +@@ -75,7 +75,8 @@ static void mmc_host_classdev_release(st + { + struct mmc_host *host = cls_dev_to_mmc_host(dev); + wakeup_source_unregister(host->ws); +- ida_simple_remove(&mmc_host_ida, host->index); ++ if (of_alias_get_id(host->parent->of_node, "mmc") < 0) ++ ida_simple_remove(&mmc_host_ida, host->index); + kfree(host); + } + +@@ -499,7 +500,7 @@ static int mmc_first_nonreserved_index(v + */ + struct mmc_host *mmc_alloc_host(int extra, struct device *dev) + { +- int err; ++ int index; + struct mmc_host *host; + int alias_id, min_idx, max_idx; + +@@ -512,20 +513,19 @@ struct mmc_host *mmc_alloc_host(int extr + + alias_id = of_alias_get_id(dev->of_node, "mmc"); + if (alias_id >= 0) { +- min_idx = alias_id; +- max_idx = alias_id + 1; ++ index = alias_id; + } else { + min_idx = mmc_first_nonreserved_index(); + max_idx = 0; +- } + +- err = ida_simple_get(&mmc_host_ida, min_idx, max_idx, GFP_KERNEL); +- if (err < 0) { +- kfree(host); +- return NULL; ++ index = ida_simple_get(&mmc_host_ida, min_idx, max_idx, GFP_KERNEL); ++ if (index < 0) { ++ kfree(host); ++ return NULL; ++ } + } + +- host->index = err; ++ host->index = index; + + dev_set_name(&host->class_dev, "mmc%d", host->index); + host->ws = wakeup_source_register(NULL, dev_name(&host->class_dev)); diff --git a/queue-5.13/revert-usb-renesas-xhci-fix-handling-of-unknown-rom-state.patch b/queue-5.13/revert-usb-renesas-xhci-fix-handling-of-unknown-rom-state.patch new file mode 100644 index 00000000000..d8ee1b69b76 --- /dev/null +++ b/queue-5.13/revert-usb-renesas-xhci-fix-handling-of-unknown-rom-state.patch @@ -0,0 +1,65 @@ +From 44cf53602f5a0db80d53c8fff6cdbcae59650a42 Mon Sep 17 00:00:00 2001 +From: Moritz Fischer +Date: Mon, 19 Jul 2021 00:05:19 -0700 +Subject: Revert "usb: renesas-xhci: Fix handling of unknown ROM state" + +From: Moritz Fischer + +commit 44cf53602f5a0db80d53c8fff6cdbcae59650a42 upstream. + +This reverts commit d143825baf15f204dac60acdf95e428182aa3374. + +Justin reports some of his systems now fail as result of this commit: + + xhci_hcd 0000:04:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2 + xhci_hcd 0000:04:00.0: request_firmware failed: -2 + xhci_hcd: probe of 0000:04:00.0 failed with error -2 + +The revert brings back the original issue the commit tried to solve but +at least unbreaks existing systems relying on previous behavior. + +Cc: stable@vger.kernel.org +Cc: Mathias Nyman +Cc: Vinod Koul +Cc: Justin Forbes +Reported-by: Justin Forbes +Signed-off-by: Moritz Fischer +Fixes: d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state") +Link: https://lore.kernel.org/r/20210719070519.41114-1-mdf@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci-renesas.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/usb/host/xhci-pci-renesas.c ++++ b/drivers/usb/host/xhci-pci-renesas.c +@@ -207,8 +207,7 @@ static int renesas_check_rom_state(struc + return 0; + + case RENESAS_ROM_STATUS_NO_RESULT: /* No result yet */ +- dev_dbg(&pdev->dev, "Unknown ROM status ...\n"); +- break; ++ return 0; + + case RENESAS_ROM_STATUS_ERROR: /* Error State */ + default: /* All other states are marked as "Reserved states" */ +@@ -225,12 +224,13 @@ static int renesas_fw_check_running(stru + u8 fw_state; + int err; + +- /* +- * Only if device has ROM and loaded FW we can skip loading and +- * return success. Otherwise (even unknown state), attempt to load FW. +- */ +- if (renesas_check_rom(pdev) && !renesas_check_rom_state(pdev)) +- return 0; ++ /* Check if device has ROM and loaded, if so skip everything */ ++ err = renesas_check_rom(pdev); ++ if (err) { /* we have rom */ ++ err = renesas_check_rom_state(pdev); ++ if (!err) ++ return err; ++ } + + /* + * Test if the device is actually needing the firmware. As most diff --git a/queue-5.13/s390-boot-fix-use-of-expolines-in-the-dma-code.patch b/queue-5.13/s390-boot-fix-use-of-expolines-in-the-dma-code.patch new file mode 100644 index 00000000000..486867e90b1 --- /dev/null +++ b/queue-5.13/s390-boot-fix-use-of-expolines-in-the-dma-code.patch @@ -0,0 +1,64 @@ +From 463f36c76fa4ec015c640ff63ccf52e7527abee0 Mon Sep 17 00:00:00 2001 +From: Alexander Egorenkov +Date: Fri, 16 Jul 2021 22:00:22 +0200 +Subject: s390/boot: fix use of expolines in the DMA code + +From: Alexander Egorenkov + +commit 463f36c76fa4ec015c640ff63ccf52e7527abee0 upstream. + +The DMA code section of the decompressor must be compiled with expolines +if Spectre V2 mitigation has been enabled for the decompressed kernel. +This is required because although the decompressor's image contains +the DMA code section, it is handed over to the decompressed kernel for use. + +Because the DMA code is already slow w/o expolines, use expolines always +regardless whether the decompressed kernel is using them or not. This +simplifies the DMA code by dropping the conditional compilation of +expolines. + +Fixes: bf72630130c2 ("s390: use proper expoline sections for .dma code") +Cc: # 5.2 +Signed-off-by: Alexander Egorenkov +Reviewed-by: Heiko Carstens +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/boot/text_dma.S | 19 ++++--------------- + 1 file changed, 4 insertions(+), 15 deletions(-) + +--- a/arch/s390/boot/text_dma.S ++++ b/arch/s390/boot/text_dma.S +@@ -9,16 +9,6 @@ + #include + #include + +-#ifdef CC_USING_EXPOLINE +- .pushsection .dma.text.__s390_indirect_jump_r14,"axG" +-__dma__s390_indirect_jump_r14: +- larl %r1,0f +- ex 0,0(%r1) +- j . +-0: br %r14 +- .popsection +-#endif +- + .section .dma.text,"ax" + /* + * Simplified version of expoline thunk. The normal thunks can not be used here, +@@ -27,11 +17,10 @@ __dma__s390_indirect_jump_r14: + * affects a few functions that are not performance-relevant. + */ + .macro BR_EX_DMA_r14 +-#ifdef CC_USING_EXPOLINE +- jg __dma__s390_indirect_jump_r14 +-#else +- br %r14 +-#endif ++ larl %r1,0f ++ ex 0,0(%r1) ++ j . ++0: br %r14 + .endm + + /* diff --git a/queue-5.13/s390-ftrace-fix-ftrace_update_ftrace_func-implementation.patch b/queue-5.13/s390-ftrace-fix-ftrace_update_ftrace_func-implementation.patch new file mode 100644 index 00000000000..93c6a403281 --- /dev/null +++ b/queue-5.13/s390-ftrace-fix-ftrace_update_ftrace_func-implementation.patch @@ -0,0 +1,129 @@ +From f8c2602733c953ed7a16e060640b8e96f9d94b9b Mon Sep 17 00:00:00 2001 +From: Vasily Gorbik +Date: Fri, 25 Jun 2021 23:50:07 +0200 +Subject: s390/ftrace: fix ftrace_update_ftrace_func implementation + +From: Vasily Gorbik + +commit f8c2602733c953ed7a16e060640b8e96f9d94b9b upstream. + +s390 enforces DYNAMIC_FTRACE if FUNCTION_TRACER is selected. +At the same time implementation of ftrace_caller is not compliant with +HAVE_DYNAMIC_FTRACE since it doesn't provide implementation of +ftrace_update_ftrace_func() and calls ftrace_trace_function() directly. + +The subtle difference is that during ftrace code patching ftrace +replaces function tracer via ftrace_update_ftrace_func() and activates +it back afterwards. Unexpected direct calls to ftrace_trace_function() +during ftrace code patching leads to nullptr-dereferences when tracing +is activated for one of functions which are used during code patching. +Those function currently are: +copy_from_kernel_nofault() +copy_from_kernel_nofault_allowed() +preempt_count_sub() [with debug_defconfig] +preempt_count_add() [with debug_defconfig] + +Corresponding KASAN report: + BUG: KASAN: nullptr-dereference in function_trace_call+0x316/0x3b0 + Read of size 4 at addr 0000000000001e08 by task migration/0/15 + + CPU: 0 PID: 15 Comm: migration/0 Tainted: G B 5.13.0-41423-g08316af3644d + Hardware name: IBM 3906 M04 704 (LPAR) + Stopper: multi_cpu_stop+0x0/0x3e0 <- stop_machine_cpuslocked+0x1e4/0x218 + Call Trace: + [<0000000001f77caa>] show_stack+0x16a/0x1d0 + [<0000000001f8de42>] dump_stack+0x15a/0x1b0 + [<0000000001f81d56>] print_address_description.constprop.0+0x66/0x2e0 + [<000000000082b0ca>] kasan_report+0x152/0x1c0 + [<00000000004cfd8e>] function_trace_call+0x316/0x3b0 + [<0000000001fb7082>] ftrace_caller+0x7a/0x7e + [<00000000006bb3e6>] copy_from_kernel_nofault_allowed+0x6/0x10 + [<00000000006bb42e>] copy_from_kernel_nofault+0x3e/0xd0 + [<000000000014605c>] ftrace_make_call+0xb4/0x1f8 + [<000000000047a1b4>] ftrace_replace_code+0x134/0x1d8 + [<000000000047a6e0>] ftrace_modify_all_code+0x120/0x1d0 + [<000000000047a7ec>] __ftrace_modify_code+0x5c/0x78 + [<000000000042395c>] multi_cpu_stop+0x224/0x3e0 + [<0000000000423212>] cpu_stopper_thread+0x33a/0x5a0 + [<0000000000243ff2>] smpboot_thread_fn+0x302/0x708 + [<00000000002329ea>] kthread+0x342/0x408 + [<00000000001066b2>] __ret_from_fork+0x92/0xf0 + [<0000000001fb57fa>] ret_from_fork+0xa/0x30 + + The buggy address belongs to the page: + page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1 + flags: 0x1ffff00000001000(reserved|node=0|zone=0|lastcpupid=0x1ffff) + raw: 1ffff00000001000 0000040000000048 0000040000000048 0000000000000000 + raw: 0000000000000000 0000000000000000 ffffffff00000001 0000000000000000 + page dumped because: kasan: bad access detected + + Memory state around the buggy address: + 0000000000001d00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 + 0000000000001d80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 + >0000000000001e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 + ^ + 0000000000001e80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 + 0000000000001f00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 + ================================================================== + +To fix that introduce ftrace_func callback to be called from +ftrace_caller and update it in ftrace_update_ftrace_func(). + +Fixes: 4cc9bed034d1 ("[S390] cleanup ftrace backend functions") +Cc: stable@vger.kernel.org +Reviewed-by: Heiko Carstens +Signed-off-by: Vasily Gorbik +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/include/asm/ftrace.h | 1 + + arch/s390/kernel/ftrace.c | 2 ++ + arch/s390/kernel/mcount.S | 4 ++-- + 3 files changed, 5 insertions(+), 2 deletions(-) + +--- a/arch/s390/include/asm/ftrace.h ++++ b/arch/s390/include/asm/ftrace.h +@@ -19,6 +19,7 @@ void ftrace_caller(void); + + extern char ftrace_graph_caller_end; + extern unsigned long ftrace_plt; ++extern void *ftrace_func; + + struct dyn_arch_ftrace { }; + +--- a/arch/s390/kernel/ftrace.c ++++ b/arch/s390/kernel/ftrace.c +@@ -40,6 +40,7 @@ + * trampoline (ftrace_plt), which clobbers also r1. + */ + ++void *ftrace_func __read_mostly = ftrace_stub; + unsigned long ftrace_plt; + + int ftrace_modify_call(struct dyn_ftrace *rec, unsigned long old_addr, +@@ -85,6 +86,7 @@ int ftrace_make_call(struct dyn_ftrace * + + int ftrace_update_ftrace_func(ftrace_func_t func) + { ++ ftrace_func = func; + return 0; + } + +--- a/arch/s390/kernel/mcount.S ++++ b/arch/s390/kernel/mcount.S +@@ -59,13 +59,13 @@ ENTRY(ftrace_caller) + #ifdef CONFIG_HAVE_MARCH_Z196_FEATURES + aghik %r2,%r0,-MCOUNT_INSN_SIZE + lgrl %r4,function_trace_op +- lgrl %r1,ftrace_trace_function ++ lgrl %r1,ftrace_func + #else + lgr %r2,%r0 + aghi %r2,-MCOUNT_INSN_SIZE + larl %r4,function_trace_op + lg %r4,0(%r4) +- larl %r1,ftrace_trace_function ++ larl %r1,ftrace_func + lg %r1,0(%r1) + #endif + lgr %r3,%r14 diff --git a/queue-5.13/series b/queue-5.13/series index bf6d9e7b7ac..8aea8c24430 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -142,3 +142,18 @@ cifs-only-write-64kb-at-a-time-when-fallocating-a-sm.patch cifs-fix-fallocate-when-trying-to-allocate-a-hole.patch proc-avoid-mixing-integer-types-in-mem_rw.patch acpi-fix-null-pointer-dereference.patch +io_uring-fix-race-condition-when-sqp-thread-goes-to-sleep.patch +mmc-core-don-t-allocate-ida-for-of-aliases.patch +s390-ftrace-fix-ftrace_update_ftrace_func-implementation.patch +s390-boot-fix-use-of-expolines-in-the-dma-code.patch +alsa-usb-audio-add-missing-proc-text-entry-for-bespoken-type.patch +alsa-usb-audio-add-registration-quirk-for-jbl-quantum-headsets.patch +alsa-sb-fix-potential-abba-deadlock-in-csp-driver.patch +alsa-hda-realtek-fix-pop-noise-and-2-front-mic-issues-on-a-machine.patch +alsa-hdmi-expose-all-pins-on-msi-ms-7c94-board.patch +alsa-pcm-call-substream-ack-method-upon-compat-mmap-commit.patch +alsa-pcm-fix-mmap-capability-check.patch +revert-usb-renesas-xhci-fix-handling-of-unknown-rom-state.patch +usb-xhci-avoid-renesas_usb_fw.mem-when-it-s-unusable.patch +xhci-fix-lost-usb-2-remote-wake.patch +usb-ehci-prevent-missed-ehci-interrupts-with-edge-triggered-msi.patch diff --git a/queue-5.13/usb-ehci-prevent-missed-ehci-interrupts-with-edge-triggered-msi.patch b/queue-5.13/usb-ehci-prevent-missed-ehci-interrupts-with-edge-triggered-msi.patch new file mode 100644 index 00000000000..f94ee0e37f0 --- /dev/null +++ b/queue-5.13/usb-ehci-prevent-missed-ehci-interrupts-with-edge-triggered-msi.patch @@ -0,0 +1,82 @@ +From 0b60557230adfdeb8164e0b342ac9cd469a75759 Mon Sep 17 00:00:00 2001 +From: David Jeffery +Date: Thu, 15 Jul 2021 17:37:44 -0400 +Subject: usb: ehci: Prevent missed ehci interrupts with edge-triggered MSI + +From: David Jeffery + +commit 0b60557230adfdeb8164e0b342ac9cd469a75759 upstream. + +When MSI is used by the ehci-hcd driver, it can cause lost interrupts which +results in EHCI only continuing to work due to a polling fallback. But the +reliance of polling drastically reduces performance of any I/O through EHCI. + +Interrupts are lost as the EHCI interrupt handler does not safely handle +edge-triggered interrupts. It fails to ensure all interrupt status bits are +cleared, which works with level-triggered interrupts but not the +edge-triggered interrupts typical from using MSI. + +To fix this problem, check if the driver may have raced with the hardware +setting additional interrupt status bits and clear status until it is in a +stable state. + +Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices") +Tested-by: Laurence Oberman +Reviewed-by: Andy Shevchenko +Acked-by: Alan Stern +Signed-off-by: David Jeffery +Link: https://lore.kernel.org/r/20210715213744.GA44506@redhat +Cc: stable +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/ehci-hcd.c | 18 ++++++++++++++---- + 1 file changed, 14 insertions(+), 4 deletions(-) + +--- a/drivers/usb/host/ehci-hcd.c ++++ b/drivers/usb/host/ehci-hcd.c +@@ -703,24 +703,28 @@ EXPORT_SYMBOL_GPL(ehci_setup); + static irqreturn_t ehci_irq (struct usb_hcd *hcd) + { + struct ehci_hcd *ehci = hcd_to_ehci (hcd); +- u32 status, masked_status, pcd_status = 0, cmd; ++ u32 status, current_status, masked_status, pcd_status = 0; ++ u32 cmd; + int bh; + + spin_lock(&ehci->lock); + +- status = ehci_readl(ehci, &ehci->regs->status); ++ status = 0; ++ current_status = ehci_readl(ehci, &ehci->regs->status); ++restart: + + /* e.g. cardbus physical eject */ +- if (status == ~(u32) 0) { ++ if (current_status == ~(u32) 0) { + ehci_dbg (ehci, "device removed\n"); + goto dead; + } ++ status |= current_status; + + /* + * We don't use STS_FLR, but some controllers don't like it to + * remain on, so mask it out along with the other status bits. + */ +- masked_status = status & (INTR_MASK | STS_FLR); ++ masked_status = current_status & (INTR_MASK | STS_FLR); + + /* Shared IRQ? */ + if (!masked_status || unlikely(ehci->rh_state == EHCI_RH_HALTED)) { +@@ -730,6 +734,12 @@ static irqreturn_t ehci_irq (struct usb_ + + /* clear (just) interrupts */ + ehci_writel(ehci, masked_status, &ehci->regs->status); ++ ++ /* For edge interrupts, don't race with an interrupt bit being raised */ ++ current_status = ehci_readl(ehci, &ehci->regs->status); ++ if (current_status & INTR_MASK) ++ goto restart; ++ + cmd = ehci_readl(ehci, &ehci->regs->command); + bh = 0; + diff --git a/queue-5.13/usb-xhci-avoid-renesas_usb_fw.mem-when-it-s-unusable.patch b/queue-5.13/usb-xhci-avoid-renesas_usb_fw.mem-when-it-s-unusable.patch new file mode 100644 index 00000000000..5ccfa9c161a --- /dev/null +++ b/queue-5.13/usb-xhci-avoid-renesas_usb_fw.mem-when-it-s-unusable.patch @@ -0,0 +1,45 @@ +From 0665e387318607d8269bfdea60723c627c8bae43 Mon Sep 17 00:00:00 2001 +From: Greg Thelen +Date: Fri, 2 Jul 2021 00:12:24 -0700 +Subject: usb: xhci: avoid renesas_usb_fw.mem when it's unusable + +From: Greg Thelen + +commit 0665e387318607d8269bfdea60723c627c8bae43 upstream. + +Commit a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with +memory") added renesas_usb_fw.mem firmware reference to xhci-pci. Thus +modinfo indicates xhci-pci.ko has "firmware: renesas_usb_fw.mem". But +the firmware is only actually used with CONFIG_USB_XHCI_PCI_RENESAS. An +unusable firmware reference can trigger safety checkers which look for +drivers with unmet firmware dependencies. + +Avoid referring to renesas_usb_fw.mem in circumstances when it cannot be +loaded (when CONFIG_USB_XHCI_PCI_RENESAS isn't set). + +Fixes: a66d21d7dba8 ("usb: xhci: Add support for Renesas controller with memory") +Cc: stable +Signed-off-by: Greg Thelen +Link: https://lore.kernel.org/r/20210702071224.3673568-1-gthelen@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -636,7 +636,14 @@ static const struct pci_device_id pci_id + { /* end: all zeroes */ } + }; + MODULE_DEVICE_TABLE(pci, pci_ids); ++ ++/* ++ * Without CONFIG_USB_XHCI_PCI_RENESAS renesas_xhci_check_request_fw() won't ++ * load firmware, so don't encumber the xhci-pci driver with it. ++ */ ++#if IS_ENABLED(CONFIG_USB_XHCI_PCI_RENESAS) + MODULE_FIRMWARE("renesas_usb_fw.mem"); ++#endif + + /* pci driver glue; this is a "new style" PCI driver module */ + static struct pci_driver xhci_pci_driver = { diff --git a/queue-5.13/xhci-fix-lost-usb-2-remote-wake.patch b/queue-5.13/xhci-fix-lost-usb-2-remote-wake.patch new file mode 100644 index 00000000000..64313e143ed --- /dev/null +++ b/queue-5.13/xhci-fix-lost-usb-2-remote-wake.patch @@ -0,0 +1,69 @@ +From 72f68bf5c756f5ce1139b31daae2684501383ad5 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Thu, 15 Jul 2021 18:06:51 +0300 +Subject: xhci: Fix lost USB 2 remote wake + +From: Mathias Nyman + +commit 72f68bf5c756f5ce1139b31daae2684501383ad5 upstream. + +There's a small window where a USB 2 remote wake may be left unhandled +due to a race between hub thread and xhci port event interrupt handler. + +When the resume event is detected in the xhci interrupt handler it kicks +the hub timer, which should move the port from resume to U0 once resume +has been signalled for long enough. + +To keep the hub "thread" running we set a bus_state->resuming_ports flag. +This flag makes sure hub timer function kicks itself. + +checking this flag was not properly protected by the spinlock. Flag was +copied to a local variable before lock was taken. The local variable was +then checked later with spinlock held. + +If interrupt is handled right after copying the flag to the local variable +we end up stopping the hub thread before it can handle the USB 2 resume. + +CPU0 CPU1 +(hub thread) (xhci event handler) + +xhci_hub_status_data() +status = bus_state->resuming_ports; + + handle_port_status() + spin_lock() + bus_state->resuming_ports = 1 + set_flag(HCD_FLAG_POLL_RH) + spin_unlock() +spin_lock() +if (!status) + clear_flag(HCD_FLAG_POLL_RH) +spin_unlock() + +Fix this by taking the lock a bit earlier so that it covers +the resuming_ports flag copy in the hub thread + +Cc: +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20210715150651.1996099-2-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-hub.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci-hub.c ++++ b/drivers/usb/host/xhci-hub.c +@@ -1638,11 +1638,12 @@ int xhci_hub_status_data(struct usb_hcd + * Inform the usbcore about resume-in-progress by returning + * a non-zero value even if there are no status changes. + */ ++ spin_lock_irqsave(&xhci->lock, flags); ++ + status = bus_state->resuming_ports; + + mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC; + +- spin_lock_irqsave(&xhci->lock, flags); + /* For each port, did anything change? If so, set that bit in buf. */ + for (i = 0; i < max_ports; i++) { + temp = readl(ports[i]->addr);