From: Greg Kroah-Hartman Date: Fri, 23 Sep 2022 17:57:54 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v4.9.330~80 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2cef43ff9e69c6c3d0e53b19fe56947e46d3d1af;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: alsa-hda-add-intel-5-series-3400-pci-did.patch alsa-hda-realtek-add-pincfg-for-asus-g513-hp-jack.patch alsa-hda-realtek-add-pincfg-for-asus-g533z-hp-jack.patch alsa-hda-realtek-add-quirk-for-asus-ga503r-laptop.patch alsa-hda-realtek-add-quirk-for-huawei-wrt-wx9.patch alsa-hda-realtek-enable-4-speaker-output-dell-precision-5530-laptop.patch alsa-hda-realtek-enable-4-speaker-output-dell-precision-5570-laptop.patch alsa-hda-realtek-re-arrange-quirk-table-entries.patch btrfs-fix-hang-during-unmount-when-stopping-a-space-reclaim-worker.patch btrfs-fix-hang-during-unmount-when-stopping-block-group-reclaim-worker.patch efi-libstub-check-shim-mode-using-moksbstatert.patch efi-x86-wipe-setup_data-on-pure-efi-boot.patch iommu-vt-d-check-correct-capability-for-sagaw-determination.patch media-flexcop-usb-fix-endpoint-type-check.patch thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch usb-dwc3-core-leave-default-dma-if-the-controller-does-not-support-64-bit-dma.patch --- diff --git a/queue-5.15/alsa-hda-add-intel-5-series-3400-pci-did.patch b/queue-5.15/alsa-hda-add-intel-5-series-3400-pci-did.patch new file mode 100644 index 00000000000..834e70b1d67 --- /dev/null +++ b/queue-5.15/alsa-hda-add-intel-5-series-3400-pci-did.patch @@ -0,0 +1,34 @@ +From 4d40ceef4745536289012670103c59264e0fb3ec Mon Sep 17 00:00:00 2001 +From: Kai Vehmanen +Date: Mon, 12 Sep 2022 21:37:16 +0300 +Subject: ALSA: hda: add Intel 5 Series / 3400 PCI DID + +From: Kai Vehmanen + +commit 4d40ceef4745536289012670103c59264e0fb3ec upstream. + +Handle 0x3b57 variant with same AZX_DCAPS_INTEL_PCH_NOPM +capabilities as 0x3b56. In practise this allow use of HDMI/DP +display audio via i915. + +BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/2751 +Signed-off-by: Kai Vehmanen +Cc: +Link: https://lore.kernel.org/r/20220912183716.2126312-1-kai.vehmanen@linux.intel.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/hda_intel.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -2519,6 +2519,8 @@ static const struct pci_device_id azx_id + /* 5 Series/3400 */ + { PCI_DEVICE(0x8086, 0x3b56), + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_NOPM }, ++ { PCI_DEVICE(0x8086, 0x3b57), ++ .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_NOPM }, + /* Poulsbo */ + { PCI_DEVICE(0x8086, 0x811b), + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_BASE }, diff --git a/queue-5.15/alsa-hda-realtek-add-pincfg-for-asus-g513-hp-jack.patch b/queue-5.15/alsa-hda-realtek-add-pincfg-for-asus-g513-hp-jack.patch new file mode 100644 index 00000000000..93cd791d030 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-add-pincfg-for-asus-g513-hp-jack.patch @@ -0,0 +1,56 @@ +From c611e659044168e7abcbae8ba1ea833521498fbb Mon Sep 17 00:00:00 2001 +From: "Luke D. Jones" +Date: Thu, 15 Sep 2022 20:09:19 +1200 +Subject: ALSA: hda/realtek: Add pincfg for ASUS G513 HP jack + +From: Luke D. Jones + +commit c611e659044168e7abcbae8ba1ea833521498fbb upstream. + +Fixes up the pincfg for ASUS ROG Strix G513 headphone and mic combo jack + +[ Fixed the position in the quirk table by tiwai ] + +Signed-off-by: Luke D. Jones +Cc: +Link: https://lore.kernel.org/r/20220915080921.35563-2-luke@ljones.dev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6879,6 +6879,7 @@ enum { + ALC294_FIXUP_ASUS_GU502_HP, + ALC294_FIXUP_ASUS_GU502_PINS, + ALC294_FIXUP_ASUS_GU502_VERBS, ++ ALC294_FIXUP_ASUS_G513_PINS, + ALC285_FIXUP_HP_GPIO_LED, + ALC285_FIXUP_HP_MUTE_LED, + ALC236_FIXUP_HP_GPIO_LED, +@@ -8206,6 +8207,15 @@ static const struct hda_fixup alc269_fix + .type = HDA_FIXUP_FUNC, + .v.func = alc294_fixup_gu502_hp, + }, ++ [ALC294_FIXUP_ASUS_G513_PINS] = { ++ .type = HDA_FIXUP_PINS, ++ .v.pins = (const struct hda_pintbl[]) { ++ { 0x19, 0x03a11050 }, /* front HP mic */ ++ { 0x1a, 0x03a11c30 }, /* rear external mic */ ++ { 0x21, 0x03211420 }, /* front HP out */ ++ { } ++ }, ++ }, + [ALC294_FIXUP_ASUS_COEF_1B] = { + .type = HDA_FIXUP_VERBS, + .v.verbs = (const struct hda_verb[]) { +@@ -9008,6 +9018,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x1d4e, "ASUS TM420", ALC256_FIXUP_ASUS_HPE), + SND_PCI_QUIRK(0x1043, 0x1e11, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA502), + SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS), ++ SND_PCI_QUIRK(0x1043, 0x1e5e, "ASUS ROG Strix G513", ALC294_FIXUP_ASUS_G513_PINS), + SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2), diff --git a/queue-5.15/alsa-hda-realtek-add-pincfg-for-asus-g533z-hp-jack.patch b/queue-5.15/alsa-hda-realtek-add-pincfg-for-asus-g533z-hp-jack.patch new file mode 100644 index 00000000000..7856ab1e7e6 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-add-pincfg-for-asus-g533z-hp-jack.patch @@ -0,0 +1,56 @@ +From bc2c23549ccd7105eb6ff0d4f0ac519285628673 Mon Sep 17 00:00:00 2001 +From: "Luke D. Jones" +Date: Thu, 15 Sep 2022 20:09:20 +1200 +Subject: ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack + +From: Luke D. Jones + +commit bc2c23549ccd7105eb6ff0d4f0ac519285628673 upstream. + +Fixes up the pincfg for ASUS ROG Strix G15 (G533Z) headphone combo jack + +[ Fixed the position in the quirk table by tiwai ] + +Signed-off-by: Luke D. Jones +Cc: +Link: https://lore.kernel.org/r/20220915080921.35563-3-luke@ljones.dev +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6880,6 +6880,7 @@ enum { + ALC294_FIXUP_ASUS_GU502_PINS, + ALC294_FIXUP_ASUS_GU502_VERBS, + ALC294_FIXUP_ASUS_G513_PINS, ++ ALC285_FIXUP_ASUS_G533Z_PINS, + ALC285_FIXUP_HP_GPIO_LED, + ALC285_FIXUP_HP_MUTE_LED, + ALC236_FIXUP_HP_GPIO_LED, +@@ -8216,6 +8217,15 @@ static const struct hda_fixup alc269_fix + { } + }, + }, ++ [ALC285_FIXUP_ASUS_G533Z_PINS] = { ++ .type = HDA_FIXUP_PINS, ++ .v.pins = (const struct hda_pintbl[]) { ++ { 0x14, 0x90170120 }, ++ { } ++ }, ++ .chained = true, ++ .chain_id = ALC294_FIXUP_ASUS_G513_PINS, ++ }, + [ALC294_FIXUP_ASUS_COEF_1B] = { + .type = HDA_FIXUP_VERBS, + .v.verbs = (const struct hda_verb[]) { +@@ -9013,6 +9023,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC), + SND_PCI_QUIRK(0x1043, 0x1bbd, "ASUS Z550MA", ALC255_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1c23, "Asus X55U", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), ++ SND_PCI_QUIRK(0x1043, 0x1c92, "ASUS ROG Strix G15", ALC285_FIXUP_ASUS_G533Z_PINS), + SND_PCI_QUIRK(0x1043, 0x1ccd, "ASUS X555UB", ALC256_FIXUP_ASUS_MIC), + SND_PCI_QUIRK(0x1043, 0x1d42, "ASUS Zephyrus G14 2022", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x1d4e, "ASUS TM420", ALC256_FIXUP_ASUS_HPE), diff --git a/queue-5.15/alsa-hda-realtek-add-quirk-for-asus-ga503r-laptop.patch b/queue-5.15/alsa-hda-realtek-add-quirk-for-asus-ga503r-laptop.patch new file mode 100644 index 00000000000..33d10407c6c --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-add-quirk-for-asus-ga503r-laptop.patch @@ -0,0 +1,34 @@ +From ba1f818053b0668a1ce2fe86b840e81b592cc560 Mon Sep 17 00:00:00 2001 +From: "Luke D. Jones" +Date: Thu, 15 Sep 2022 20:09:21 +1200 +Subject: ALSA: hda/realtek: Add quirk for ASUS GA503R laptop + +From: Luke D. Jones + +commit ba1f818053b0668a1ce2fe86b840e81b592cc560 upstream. + +The ASUS G15 2022 (GA503R) series laptop has the same node-to-DAC pairs +as early models and the G14, this includes bass speakers which are by +default mapped incorrectly to the 0x06 node. + +Add a quirk to use the same DAC pairs as the G14. + +Signed-off-by: Luke D. Jones +Cc: +Link: https://lore.kernel.org/r/20220915080921.35563-4-luke@ljones.dev +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 +@@ -9031,6 +9031,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS), + SND_PCI_QUIRK(0x1043, 0x1e5e, "ASUS ROG Strix G513", ALC294_FIXUP_ASUS_G513_PINS), + SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401), ++ SND_PCI_QUIRK(0x1043, 0x1c52, "ASUS Zephyrus G15 2022", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2), + SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC), diff --git a/queue-5.15/alsa-hda-realtek-add-quirk-for-huawei-wrt-wx9.patch b/queue-5.15/alsa-hda-realtek-add-quirk-for-huawei-wrt-wx9.patch new file mode 100644 index 00000000000..7e43e6195a6 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-add-quirk-for-huawei-wrt-wx9.patch @@ -0,0 +1,30 @@ +From cbcdf8c4d35cd74aee8581eb2f0453e0ecab7b05 Mon Sep 17 00:00:00 2001 +From: huangwenhui +Date: Tue, 13 Sep 2022 13:46:22 +0800 +Subject: ALSA: hda/realtek: Add quirk for Huawei WRT-WX9 + +From: huangwenhui + +commit cbcdf8c4d35cd74aee8581eb2f0453e0ecab7b05 upstream. + +Fixes headphone and headset microphone detection on Huawei WRT-WX9. + +Signed-off-by: huangwenhui +Cc: +Link: https://lore.kernel.org/r/20220913054622.15979-1-huangwenhuia@uniontech.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 +@@ -9205,6 +9205,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), + SND_PCI_QUIRK(0x1849, 0x1233, "ASRock NUC Box 1100", ALC233_FIXUP_NO_AUDIO_JACK), + SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", ALC256_FIXUP_HUAWEI_MACH_WX9_PINS), ++ SND_PCI_QUIRK(0x19e5, 0x320f, "Huawei WRT-WX9 ", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1b35, 0x1235, "CZC B20", ALC269_FIXUP_CZC_B20), + SND_PCI_QUIRK(0x1b35, 0x1236, "CZC TMI", ALC269_FIXUP_CZC_TMI), + SND_PCI_QUIRK(0x1b35, 0x1237, "CZC L101", ALC269_FIXUP_CZC_L101), diff --git a/queue-5.15/alsa-hda-realtek-enable-4-speaker-output-dell-precision-5530-laptop.patch b/queue-5.15/alsa-hda-realtek-enable-4-speaker-output-dell-precision-5530-laptop.patch new file mode 100644 index 00000000000..0df30c41d56 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-enable-4-speaker-output-dell-precision-5530-laptop.patch @@ -0,0 +1,33 @@ +From 1885ff13d4c42910b37a0e3f7c2f182520f4eed1 Mon Sep 17 00:00:00 2001 +From: Callum Osmotherly +Date: Thu, 15 Sep 2022 22:36:08 +0930 +Subject: ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop + +From: Callum Osmotherly + +commit 1885ff13d4c42910b37a0e3f7c2f182520f4eed1 upstream. + +Just as with the 5570 (and the other Dell laptops), this enables the two +subwoofer speakers on the Dell Precision 5530 together with the main +ones, significantly increasing the audio quality. I've tested this +myself on a 5530 and can confirm it's working as expected. + +Signed-off-by: Callum Osmotherly +Cc: +Link: https://lore.kernel.org/r/YyMjQO3mhyXlMbCf@piranha +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 +@@ -8836,6 +8836,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC), + SND_PCI_QUIRK(0x1028, 0x0872, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC), + SND_PCI_QUIRK(0x1028, 0x0873, "Dell Precision 3930", ALC255_FIXUP_DUMMY_LINEOUT_VERB), ++ SND_PCI_QUIRK(0x1028, 0x087d, "Dell Precision 5530", ALC289_FIXUP_DUAL_SPK), + SND_PCI_QUIRK(0x1028, 0x08ad, "Dell WYSE AIO", ALC225_FIXUP_DELL_WYSE_AIO_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x08ae, "Dell WYSE NB", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x0935, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB), diff --git a/queue-5.15/alsa-hda-realtek-enable-4-speaker-output-dell-precision-5570-laptop.patch b/queue-5.15/alsa-hda-realtek-enable-4-speaker-output-dell-precision-5570-laptop.patch new file mode 100644 index 00000000000..9ac738609d9 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-enable-4-speaker-output-dell-precision-5570-laptop.patch @@ -0,0 +1,33 @@ +From bdc9b7396f7d4d6533e70fd8d5472f505b5ef58f Mon Sep 17 00:00:00 2001 +From: Callum Osmotherly +Date: Wed, 14 Sep 2022 18:44:00 +0930 +Subject: ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5570 laptop + +From: Callum Osmotherly + +commit bdc9b7396f7d4d6533e70fd8d5472f505b5ef58f upstream. + +The Dell Precision 5570 uses the same 4-speakers-on-ALC289 just like the +previous Precision 5560. I replicated that patch onto this one, and can +confirm that the audio is much better (the woofers are now working); +I've tested it on my Dell Precision 5570. + +Signed-off-by: Callum Osmotherly +Cc: +Link: https://lore.kernel.org/r/YyGbWM5wEoFMbW2v@piranha +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 +@@ -8831,6 +8831,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1028, 0x0a9d, "Dell Latitude 5430", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x0a9e, "Dell Latitude 5430", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x0b19, "Dell XPS 15 9520", ALC289_FIXUP_DUAL_SPK), ++ SND_PCI_QUIRK(0x1028, 0x0b1a, "Dell Precision 5570", ALC289_FIXUP_DUAL_SPK), + SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), diff --git a/queue-5.15/alsa-hda-realtek-re-arrange-quirk-table-entries.patch b/queue-5.15/alsa-hda-realtek-re-arrange-quirk-table-entries.patch new file mode 100644 index 00000000000..fe2ee9b9dc5 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-re-arrange-quirk-table-entries.patch @@ -0,0 +1,53 @@ +From b16c8f229a58eaddfc58aab447253464abd3c85e Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 15 Sep 2022 17:47:24 +0200 +Subject: ALSA: hda/realtek: Re-arrange quirk table entries + +From: Takashi Iwai + +commit b16c8f229a58eaddfc58aab447253464abd3c85e upstream. + +A few entries have been mistakenly inserted in wrong positions without +considering the SSID ordering. Place them at right positions. + +Fixes: b7557267c233 ("ALSA: hda/realtek: Add quirk for ASUS GA402") +Fixes: 94db9cc8f8fa ("ALSA: hda/realtek: Add quirk for ASUS GU603") +Fixes: 739d0959fbed ("ALSA: hda: Add quirk for ASUS Flow x13") +Cc: +Link: https://lore.kernel.org/r/20220915154724.31634-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -8984,10 +8984,11 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC), + SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), + SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A), ++ SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK), ++ SND_PCI_QUIRK(0x1043, 0x16b2, "ASUS GU603", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1043, 0x1740, "ASUS UX430UA", ALC295_FIXUP_ASUS_DACS), + SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_DUAL_SPK), +- SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK), + SND_PCI_QUIRK(0x1043, 0x1881, "ASUS Zephyrus S/M", ALC294_FIXUP_ASUS_GX502_PINS), + SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA", ALC256_FIXUP_ASUS_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT", ALC256_FIXUP_ASUS_HEADSET_MIC), +@@ -9003,13 +9004,12 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x1bbd, "ASUS Z550MA", ALC255_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1c23, "Asus X55U", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), + SND_PCI_QUIRK(0x1043, 0x1ccd, "ASUS X555UB", ALC256_FIXUP_ASUS_MIC), ++ SND_PCI_QUIRK(0x1043, 0x1d42, "ASUS Zephyrus G14 2022", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x1d4e, "ASUS TM420", ALC256_FIXUP_ASUS_HPE), + SND_PCI_QUIRK(0x1043, 0x1e11, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA502), + SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS), + SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401), +- SND_PCI_QUIRK(0x1043, 0x1d42, "ASUS Zephyrus G14 2022", ALC289_FIXUP_ASUS_GA401), +- SND_PCI_QUIRK(0x1043, 0x16b2, "ASUS GU603", ALC289_FIXUP_ASUS_GA401), + SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2), + SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1043, 0x834a, "ASUS S101", ALC269_FIXUP_STEREO_DMIC), diff --git a/queue-5.15/btrfs-fix-hang-during-unmount-when-stopping-a-space-reclaim-worker.patch b/queue-5.15/btrfs-fix-hang-during-unmount-when-stopping-a-space-reclaim-worker.patch new file mode 100644 index 00000000000..55cdbe6a2bc --- /dev/null +++ b/queue-5.15/btrfs-fix-hang-during-unmount-when-stopping-a-space-reclaim-worker.patch @@ -0,0 +1,160 @@ +From a362bb864b8db4861977d00bd2c3222503ccc34b Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 8 Sep 2022 12:31:51 +0100 +Subject: btrfs: fix hang during unmount when stopping a space reclaim worker + +From: Filipe Manana + +commit a362bb864b8db4861977d00bd2c3222503ccc34b upstream. + +Often when running generic/562 from fstests we can hang during unmount, +resulting in a trace like this: + + Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 + Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. + Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 + Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. + Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 + Sep 07 11:55:32 debian9 kernel: Call Trace: + Sep 07 11:55:32 debian9 kernel: + Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 + Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 + Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 + Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 + Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 + Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 + Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 + Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 + Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0 + Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530 + Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140 + Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30 + Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0 + Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs] + Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170 + Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs] + Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0 + Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120 + Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30 + Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs] + Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0 + Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160 + Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0 + Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0 + Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40 + Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90 + Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd + Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7 + Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 + Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 + Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0 + Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 + Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 + Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 + Sep 07 11:55:32 debian9 kernel: + +What happens is the following: + +1) The cleaner kthread tries to start a transaction to delete an unused + block group, but the metadata reservation can not be satisfied right + away, so a reservation ticket is created and it starts the async + metadata reclaim task (fs_info->async_reclaim_work); + +2) Writeback for all the filler inodes with an i_size of 2K starts + (generic/562 creates a lot of 2K files with the goal of filling + metadata space). We try to create an inline extent for them, but we + fail when trying to insert the inline extent with -ENOSPC (at + cow_file_range_inline()) - since this is not critical, we fallback + to non-inline mode (back to cow_file_range()), reserve extents, create + extent maps and create the ordered extents; + +3) An unmount starts, enters close_ctree(); + +4) The async reclaim task is flushing stuff, entering the flush states one + by one, until it reaches RUN_DELAYED_IPUTS. There it runs all current + delayed iputs. + + After running the delayed iputs and before calling + btrfs_wait_on_delayed_iputs(), one or more ordered extents complete, + and btrfs_add_delayed_iput() is called for each one through + btrfs_finish_ordered_io() -> btrfs_put_ordered_extent(). This results + in bumping fs_info->nr_delayed_iputs from 0 to some positive value. + + So the async reclaim task blocks at btrfs_wait_on_delayed_iputs() waiting + for fs_info->nr_delayed_iputs to become 0; + +5) The current transaction is committed by the transaction kthread, we then + start unpinning extents and end up calling btrfs_try_granting_tickets() + through unpin_extent_range(), since we released some space. + This results in satisfying the ticket created by the cleaner kthread at + step 1, waking up the cleaner kthread; + +6) At close_ctree() we ask the cleaner kthread to park; + +7) The cleaner kthread starts the transaction, deletes the unused block + group, and then calls kthread_should_park(), which returns true, so it + parks. And at this point we have the delayed iputs added by the + completion of the ordered extents still pending; + +8) Then later at close_ctree(), when we call: + + cancel_work_sync(&fs_info->async_reclaim_work); + + We hang forever, since the cleaner was parked and no one else can run + delayed iputs after that, while the reclaim task is waiting for the + remaining delayed iputs to be completed. + +Fix this by waiting for all ordered extents to complete and running the +delayed iputs before attempting to stop the async reclaim tasks. Note that +we can not wait for ordered extents with btrfs_wait_ordered_roots() (or +other similar functions) because that waits for the BTRFS_ORDERED_COMPLETE +flag to be set on an ordered extent, but the delayed iput is added after +that, when doing the final btrfs_put_ordered_extent(). So instead wait for +the work queues used for executing ordered extent completion to be empty, +which works because we do the final put on an ordered extent at +btrfs_finish_ordered_io() (while we are in the unmount context). + +Fixes: d6fd0ae25c6495 ("Btrfs: fix missing delayed iputs on unmount") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 25 +++++++++++++++++++++++++ + 1 file changed, 25 insertions(+) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -4348,6 +4348,31 @@ void __cold close_ctree(struct btrfs_fs_ + /* clear out the rbtree of defraggable inodes */ + btrfs_cleanup_defrag_inodes(fs_info); + ++ /* ++ * After we parked the cleaner kthread, ordered extents may have ++ * completed and created new delayed iputs. If one of the async reclaim ++ * tasks is running and in the RUN_DELAYED_IPUTS flush state, then we ++ * can hang forever trying to stop it, because if a delayed iput is ++ * added after it ran btrfs_run_delayed_iputs() and before it called ++ * btrfs_wait_on_delayed_iputs(), it will hang forever since there is ++ * no one else to run iputs. ++ * ++ * So wait for all ongoing ordered extents to complete and then run ++ * delayed iputs. This works because once we reach this point no one ++ * can either create new ordered extents nor create delayed iputs ++ * through some other means. ++ * ++ * Also note that btrfs_wait_ordered_roots() is not safe here, because ++ * it waits for BTRFS_ORDERED_COMPLETE to be set on an ordered extent, ++ * but the delayed iput for the respective inode is made only when doing ++ * the final btrfs_put_ordered_extent() (which must happen at ++ * btrfs_finish_ordered_io() when we are unmounting). ++ */ ++ btrfs_flush_workqueue(fs_info->endio_write_workers); ++ /* Ordered extents for free space inodes. */ ++ btrfs_flush_workqueue(fs_info->endio_freespace_worker); ++ btrfs_run_delayed_iputs(fs_info); ++ + cancel_work_sync(&fs_info->async_reclaim_work); + cancel_work_sync(&fs_info->async_data_reclaim_work); + cancel_work_sync(&fs_info->preempt_reclaim_work); diff --git a/queue-5.15/btrfs-fix-hang-during-unmount-when-stopping-block-group-reclaim-worker.patch b/queue-5.15/btrfs-fix-hang-during-unmount-when-stopping-block-group-reclaim-worker.patch new file mode 100644 index 00000000000..ff60fff1348 --- /dev/null +++ b/queue-5.15/btrfs-fix-hang-during-unmount-when-stopping-block-group-reclaim-worker.patch @@ -0,0 +1,65 @@ +From 8a1f1e3d1eecf9d2359a2709e276743a67e145db Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 8 Sep 2022 12:31:50 +0100 +Subject: btrfs: fix hang during unmount when stopping block group reclaim worker + +From: Filipe Manana + +commit 8a1f1e3d1eecf9d2359a2709e276743a67e145db upstream. + +During early unmount, at close_ctree(), we try to stop the block group +reclaim task with cancel_work_sync(), but that may hang if the block group +reclaim task is currently at btrfs_relocate_block_group() waiting for the +flag BTRFS_FS_UNFINISHED_DROPS to be cleared from fs_info->flags. During +unmount we only clear that flag later, after trying to stop the block +group reclaim task. + +Fix that by clearing BTRFS_FS_UNFINISHED_DROPS before trying to stop the +block group reclaim task and after setting BTRFS_FS_CLOSING_START, so that +if the reclaim task is waiting on that bit, it will stop immediately after +being woken, because it sees the filesystem is closing (with a call to +btrfs_fs_closing()), and then returns immediately with -EINTR. + +Fixes: 31e70e527806c5 ("btrfs: fix hang during unmount when block group reclaim task is running") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 17 +++++++++++------ + 1 file changed, 11 insertions(+), 6 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -4298,6 +4298,17 @@ void __cold close_ctree(struct btrfs_fs_ + set_bit(BTRFS_FS_CLOSING_START, &fs_info->flags); + + /* ++ * If we had UNFINISHED_DROPS we could still be processing them, so ++ * clear that bit and wake up relocation so it can stop. ++ * We must do this before stopping the block group reclaim task, because ++ * at btrfs_relocate_block_group() we wait for this bit, and after the ++ * wait we stop with -EINTR if btrfs_fs_closing() returns non-zero - we ++ * have just set BTRFS_FS_CLOSING_START, so btrfs_fs_closing() will ++ * return 1. ++ */ ++ btrfs_wake_unfinished_drop(fs_info); ++ ++ /* + * We may have the reclaim task running and relocating a data block group, + * in which case it may create delayed iputs. So stop it before we park + * the cleaner kthread otherwise we can get new delayed iputs after +@@ -4315,12 +4326,6 @@ void __cold close_ctree(struct btrfs_fs_ + */ + kthread_park(fs_info->cleaner_kthread); + +- /* +- * If we had UNFINISHED_DROPS we could still be processing them, so +- * clear that bit and wake up relocation so it can stop. +- */ +- btrfs_wake_unfinished_drop(fs_info); +- + /* wait for the qgroup rescan worker to stop */ + btrfs_qgroup_wait_for_completion(fs_info, false); + diff --git a/queue-5.15/efi-libstub-check-shim-mode-using-moksbstatert.patch b/queue-5.15/efi-libstub-check-shim-mode-using-moksbstatert.patch new file mode 100644 index 00000000000..f724f1757c6 --- /dev/null +++ b/queue-5.15/efi-libstub-check-shim-mode-using-moksbstatert.patch @@ -0,0 +1,63 @@ +From 5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Tue, 20 Sep 2022 17:08:23 +0200 +Subject: efi: libstub: check Shim mode using MokSBStateRT + +From: Ard Biesheuvel + +commit 5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1 upstream. + +We currently check the MokSBState variable to decide whether we should +treat UEFI secure boot as being disabled, even if the firmware thinks +otherwise. This is used by shim to indicate that it is not checking +signatures on boot images. In the kernel, we use this to relax lockdown +policies. + +However, in cases where shim is not even being used, we don't want this +variable to interfere with lockdown, given that the variable may be +non-volatile and therefore persist across a reboot. This means setting +it once will persistently disable lockdown checks on a given system. + +So switch to the mirrored version of this variable, called MokSBStateRT, +which is supposed to be volatile, and this is something we can check. + +Cc: # v4.19+ +Signed-off-by: Ard Biesheuvel +Reviewed-by: Ilias Apalodimas +Reviewed-by: Peter Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/libstub/secureboot.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/firmware/efi/libstub/secureboot.c ++++ b/drivers/firmware/efi/libstub/secureboot.c +@@ -14,7 +14,7 @@ + + /* SHIM variables */ + static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID; +-static const efi_char16_t shim_MokSBState_name[] = L"MokSBState"; ++static const efi_char16_t shim_MokSBState_name[] = L"MokSBStateRT"; + + static efi_status_t get_var(efi_char16_t *name, efi_guid_t *vendor, u32 *attr, + unsigned long *data_size, void *data) +@@ -43,8 +43,8 @@ enum efi_secureboot_mode efi_get_secureb + + /* + * See if a user has put the shim into insecure mode. If so, and if the +- * variable doesn't have the runtime attribute set, we might as well +- * honor that. ++ * variable doesn't have the non-volatile attribute set, we might as ++ * well honor that. + */ + size = sizeof(moksbstate); + status = get_efi_var(shim_MokSBState_name, &shim_guid, +@@ -53,7 +53,7 @@ enum efi_secureboot_mode efi_get_secureb + /* If it fails, we don't care why. Default to secure */ + if (status != EFI_SUCCESS) + goto secure_boot_enabled; +- if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS) && moksbstate == 1) ++ if (!(attr & EFI_VARIABLE_NON_VOLATILE) && moksbstate == 1) + return efi_secureboot_mode_disabled; + + secure_boot_enabled: diff --git a/queue-5.15/efi-x86-wipe-setup_data-on-pure-efi-boot.patch b/queue-5.15/efi-x86-wipe-setup_data-on-pure-efi-boot.patch new file mode 100644 index 00000000000..b75429364a0 --- /dev/null +++ b/queue-5.15/efi-x86-wipe-setup_data-on-pure-efi-boot.patch @@ -0,0 +1,56 @@ +From 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Thu, 4 Aug 2022 15:39:48 +0200 +Subject: efi: x86: Wipe setup_data on pure EFI boot + +From: Ard Biesheuvel + +commit 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 upstream. + +When booting the x86 kernel via EFI using the LoadImage/StartImage boot +services [as opposed to the deprecated EFI handover protocol], the setup +header is taken from the image directly, and given that EFI's LoadImage +has no Linux/x86 specific knowledge regarding struct bootparams or +struct setup_header, any absolute addresses in the setup header must +originate from the file and not from a prior loading stage. + +Since we cannot generally predict where LoadImage() decides to load an +image (*), such absolute addresses must be treated as suspect: even if a +prior boot stage intended to make them point somewhere inside the +[signed] image, there is no way to validate that, and if they point at +an arbitrary location in memory, the setup_data nodes will not be +covered by any signatures or TPM measurements either, and could be made +to contain an arbitrary sequence of SETUP_xxx nodes, which could +interfere quite badly with the early x86 boot sequence. + +(*) Note that, while LoadImage() does take a buffer/size tuple in +addition to a device path, which can be used to provide the image +contents directly, it will re-allocate such images, as the memory +footprint of an image is generally larger than the PE/COFF file +representation. + +Cc: # v5.10+ +Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/ +Signed-off-by: Ard Biesheuvel +Acked-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/libstub/x86-stub.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/firmware/efi/libstub/x86-stub.c ++++ b/drivers/firmware/efi/libstub/x86-stub.c +@@ -414,6 +414,13 @@ efi_status_t __efiapi efi_pe_entry(efi_h + hdr->ramdisk_image = 0; + hdr->ramdisk_size = 0; + ++ /* ++ * Disregard any setup data that was provided by the bootloader: ++ * setup_data could be pointing anywhere, and we have no way of ++ * authenticating or validating the payload. ++ */ ++ hdr->setup_data = 0; ++ + efi_stub_entry(handle, sys_table_arg, boot_params); + /* not reached */ + diff --git a/queue-5.15/iommu-vt-d-check-correct-capability-for-sagaw-determination.patch b/queue-5.15/iommu-vt-d-check-correct-capability-for-sagaw-determination.patch new file mode 100644 index 00000000000..404a47bd362 --- /dev/null +++ b/queue-5.15/iommu-vt-d-check-correct-capability-for-sagaw-determination.patch @@ -0,0 +1,38 @@ +From 154897807050c1161cb2660e502fc0470d46b986 Mon Sep 17 00:00:00 2001 +From: Yi Liu +Date: Wed, 21 Sep 2022 10:40:54 +0800 +Subject: iommu/vt-d: Check correct capability for sagaw determination + +From: Yi Liu + +commit 154897807050c1161cb2660e502fc0470d46b986 upstream. + +Check 5-level paging capability for 57 bits address width instead of +checking 1GB large page capability. + +Fixes: 53fc7ad6edf2 ("iommu/vt-d: Correctly calculate sagaw value of IOMMU") +Cc: stable@vger.kernel.org +Reported-by: Raghunathan Srinivasan +Signed-off-by: Yi Liu +Reviewed-by: Jerry Snitselaar +Reviewed-by: Kevin Tian +Reviewed-by: Raghunathan Srinivasan +Link: https://lore.kernel.org/r/20220916071212.2223869-2-yi.l.liu@intel.com +Signed-off-by: Lu Baolu +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/iommu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iommu/intel/iommu.c ++++ b/drivers/iommu/intel/iommu.c +@@ -539,7 +539,7 @@ static unsigned long __iommu_calculate_s + { + unsigned long fl_sagaw, sl_sagaw; + +- fl_sagaw = BIT(2) | (cap_fl1gp_support(iommu->cap) ? BIT(3) : 0); ++ fl_sagaw = BIT(2) | (cap_5lp_support(iommu->cap) ? BIT(3) : 0); + sl_sagaw = cap_sagaw(iommu->cap); + + /* Second level only. */ diff --git a/queue-5.15/media-flexcop-usb-fix-endpoint-type-check.patch b/queue-5.15/media-flexcop-usb-fix-endpoint-type-check.patch new file mode 100644 index 00000000000..54423d16ac0 --- /dev/null +++ b/queue-5.15/media-flexcop-usb-fix-endpoint-type-check.patch @@ -0,0 +1,38 @@ +From 763679f0eeff0185fc431498849bbc1c24460875 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Mon, 22 Aug 2022 17:10:27 +0200 +Subject: media: flexcop-usb: fix endpoint type check + +From: Johan Hovold + +commit 763679f0eeff0185fc431498849bbc1c24460875 upstream. + +Commit d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint +type") tried to add an endpoint type sanity check for the single +isochronous endpoint but instead broke the driver by checking the wrong +descriptor or random data beyond the last endpoint descriptor. + +Make sure to check the right endpoint descriptor. + +Fixes: d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type") +Cc: Oliver Neukum +Cc: stable@vger.kernel.org # 5.9 +Reported-by: Dongliang Mu +Signed-off-by: Johan Hovold +Link: https://lore.kernel.org/r/20220822151027.27026-1-johan@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/usb/b2c2/flexcop-usb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/usb/b2c2/flexcop-usb.c ++++ b/drivers/media/usb/b2c2/flexcop-usb.c +@@ -511,7 +511,7 @@ static int flexcop_usb_init(struct flexc + + if (fc_usb->uintf->cur_altsetting->desc.bNumEndpoints < 1) + return -ENODEV; +- if (!usb_endpoint_is_isoc_in(&fc_usb->uintf->cur_altsetting->endpoint[1].desc)) ++ if (!usb_endpoint_is_isoc_in(&fc_usb->uintf->cur_altsetting->endpoint[0].desc)) + return -ENODEV; + + switch (fc_usb->udev->speed) { diff --git a/queue-5.15/series b/queue-5.15/series index 8caa7930a46..cd1fc71c6b1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -23,3 +23,19 @@ usb-serial-option-add-quectel-rm520n.patch revert-alsa-usb-audio-split-endpoint-setups-for-hw_params-and-prepare.patch alsa-core-fix-double-free-at-snd_card_new.patch alsa-hda-tegra-set-depop-delay-for-tegra.patch +alsa-hda-add-intel-5-series-3400-pci-did.patch +alsa-hda-realtek-add-quirk-for-huawei-wrt-wx9.patch +alsa-hda-realtek-enable-4-speaker-output-dell-precision-5570-laptop.patch +alsa-hda-realtek-re-arrange-quirk-table-entries.patch +alsa-hda-realtek-add-pincfg-for-asus-g513-hp-jack.patch +alsa-hda-realtek-add-pincfg-for-asus-g533z-hp-jack.patch +alsa-hda-realtek-add-quirk-for-asus-ga503r-laptop.patch +alsa-hda-realtek-enable-4-speaker-output-dell-precision-5530-laptop.patch +iommu-vt-d-check-correct-capability-for-sagaw-determination.patch +btrfs-fix-hang-during-unmount-when-stopping-block-group-reclaim-worker.patch +btrfs-fix-hang-during-unmount-when-stopping-a-space-reclaim-worker.patch +media-flexcop-usb-fix-endpoint-type-check.patch +usb-dwc3-core-leave-default-dma-if-the-controller-does-not-support-64-bit-dma.patch +thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch +efi-x86-wipe-setup_data-on-pure-efi-boot.patch +efi-libstub-check-shim-mode-using-moksbstatert.patch diff --git a/queue-5.15/thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch b/queue-5.15/thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch new file mode 100644 index 00000000000..b7b7d9ae6f7 --- /dev/null +++ b/queue-5.15/thunderbolt-add-support-for-intel-maple-ridge-single-port-controller.patch @@ -0,0 +1,42 @@ +From 14c7d905283744809e6b82efae2f490660a11cda Mon Sep 17 00:00:00 2001 +From: Gil Fine +Date: Thu, 8 Sep 2022 13:43:20 +0300 +Subject: thunderbolt: Add support for Intel Maple Ridge single port controller + +From: Gil Fine + +commit 14c7d905283744809e6b82efae2f490660a11cda upstream. + +Add support for Maple Ridge discrete USB4 host controller from Intel +which has a single USB4 port (versus the already supported dual port +Maple Ridge USB4 host controller). + +Cc: stable@vger.kernel.org +Signed-off-by: Gil Fine +Signed-off-by: Mika Westerberg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thunderbolt/icm.c | 1 + + drivers/thunderbolt/nhi.h | 1 + + 2 files changed, 2 insertions(+) + +--- a/drivers/thunderbolt/icm.c ++++ b/drivers/thunderbolt/icm.c +@@ -2522,6 +2522,7 @@ struct tb *icm_probe(struct tb_nhi *nhi) + tb->cm_ops = &icm_icl_ops; + break; + ++ case PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_2C_NHI: + case PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_4C_NHI: + icm->is_supported = icm_tgl_is_supported; + icm->get_mode = icm_ar_get_mode; +--- a/drivers/thunderbolt/nhi.h ++++ b/drivers/thunderbolt/nhi.h +@@ -55,6 +55,7 @@ extern const struct tb_nhi_ops icl_nhi_o + * need for the PCI quirk anymore as we will use ICM also on Apple + * hardware. + */ ++#define PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_2C_NHI 0x1134 + #define PCI_DEVICE_ID_INTEL_MAPLE_RIDGE_4C_NHI 0x1137 + #define PCI_DEVICE_ID_INTEL_WIN_RIDGE_2C_NHI 0x157d + #define PCI_DEVICE_ID_INTEL_WIN_RIDGE_2C_BRIDGE 0x157e diff --git a/queue-5.15/usb-dwc3-core-leave-default-dma-if-the-controller-does-not-support-64-bit-dma.patch b/queue-5.15/usb-dwc3-core-leave-default-dma-if-the-controller-does-not-support-64-bit-dma.patch new file mode 100644 index 00000000000..79d3499b615 --- /dev/null +++ b/queue-5.15/usb-dwc3-core-leave-default-dma-if-the-controller-does-not-support-64-bit-dma.patch @@ -0,0 +1,58 @@ +From 91062e663b261815573ce00967b1895a99e668df Mon Sep 17 00:00:00 2001 +From: William Wu +Date: Thu, 1 Sep 2022 16:34:46 +0800 +Subject: usb: dwc3: core: leave default DMA if the controller does not support 64-bit DMA + +From: William Wu + +commit 91062e663b261815573ce00967b1895a99e668df upstream. + +On some DWC3 controllers (e.g. Rockchip SoCs), the DWC3 core +doesn't support 64-bit DMA address width. In this case, this +driver should use the default 32-bit mask. Otherwise, the DWC3 +controller will break if it runs on above 4GB physical memory +environment. + +This patch reads the DWC_USB3_AWIDTH bits of GHWPARAMS0 which +used for the DMA address width, and only configure 64-bit DMA +mask if the DWC_USB3_AWIDTH is 64. + +Fixes: 45d39448b4d0 ("usb: dwc3: support 64 bit DMA in platform driver") +Cc: stable +Reviewed-by: Sven Peter +Signed-off-by: William Wu +Link: https://lore.kernel.org/r/20220901083446.3799754-1-william.wu@rock-chips.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/dwc3/core.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/drivers/usb/dwc3/core.c ++++ b/drivers/usb/dwc3/core.c +@@ -1570,12 +1570,6 @@ static int dwc3_probe(struct platform_de + + dwc3_get_properties(dwc); + +- if (!dwc->sysdev_is_parent) { +- ret = dma_set_mask_and_coherent(dwc->sysdev, DMA_BIT_MASK(64)); +- if (ret) +- return ret; +- } +- + dwc->reset = devm_reset_control_array_get_optional_shared(dev); + if (IS_ERR(dwc->reset)) + return PTR_ERR(dwc->reset); +@@ -1612,6 +1606,13 @@ static int dwc3_probe(struct platform_de + platform_set_drvdata(pdev, dwc); + dwc3_cache_hwparams(dwc); + ++ if (!dwc->sysdev_is_parent && ++ DWC3_GHWPARAMS0_AWIDTH(dwc->hwparams.hwparams0) == 64) { ++ ret = dma_set_mask_and_coherent(dwc->sysdev, DMA_BIT_MASK(64)); ++ if (ret) ++ goto disable_clks; ++ } ++ + spin_lock_init(&dwc->lock); + mutex_init(&dwc->mutex); +