--- /dev/null
+From 4d40ceef4745536289012670103c59264e0fb3ec Mon Sep 17 00:00:00 2001
+From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
+Date: Mon, 12 Sep 2022 21:37:16 +0300
+Subject: ALSA: hda: add Intel 5 Series / 3400 PCI DID
+
+From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
+
+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 <kai.vehmanen@linux.intel.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220912183716.2126312-1-kai.vehmanen@linux.intel.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 },
--- /dev/null
+From c611e659044168e7abcbae8ba1ea833521498fbb Mon Sep 17 00:00:00 2001
+From: "Luke D. Jones" <luke@ljones.dev>
+Date: Thu, 15 Sep 2022 20:09:19 +1200
+Subject: ALSA: hda/realtek: Add pincfg for ASUS G513 HP jack
+
+From: Luke D. Jones <luke@ljones.dev>
+
+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 <luke@ljones.dev>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220915080921.35563-2-luke@ljones.dev
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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),
--- /dev/null
+From bc2c23549ccd7105eb6ff0d4f0ac519285628673 Mon Sep 17 00:00:00 2001
+From: "Luke D. Jones" <luke@ljones.dev>
+Date: Thu, 15 Sep 2022 20:09:20 +1200
+Subject: ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack
+
+From: Luke D. Jones <luke@ljones.dev>
+
+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 <luke@ljones.dev>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220915080921.35563-3-luke@ljones.dev
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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),
--- /dev/null
+From ba1f818053b0668a1ce2fe86b840e81b592cc560 Mon Sep 17 00:00:00 2001
+From: "Luke D. Jones" <luke@ljones.dev>
+Date: Thu, 15 Sep 2022 20:09:21 +1200
+Subject: ALSA: hda/realtek: Add quirk for ASUS GA503R laptop
+
+From: Luke D. Jones <luke@ljones.dev>
+
+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 <luke@ljones.dev>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220915080921.35563-4-luke@ljones.dev
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -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),
--- /dev/null
+From cbcdf8c4d35cd74aee8581eb2f0453e0ecab7b05 Mon Sep 17 00:00:00 2001
+From: huangwenhui <huangwenhuia@uniontech.com>
+Date: Tue, 13 Sep 2022 13:46:22 +0800
+Subject: ALSA: hda/realtek: Add quirk for Huawei WRT-WX9
+
+From: huangwenhui <huangwenhuia@uniontech.com>
+
+commit cbcdf8c4d35cd74aee8581eb2f0453e0ecab7b05 upstream.
+
+Fixes headphone and headset microphone detection on Huawei WRT-WX9.
+
+Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220913054622.15979-1-huangwenhuia@uniontech.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -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),
--- /dev/null
+From 1885ff13d4c42910b37a0e3f7c2f182520f4eed1 Mon Sep 17 00:00:00 2001
+From: Callum Osmotherly <callum.osmotherly@gmail.com>
+Date: Thu, 15 Sep 2022 22:36:08 +0930
+Subject: ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop
+
+From: Callum Osmotherly <callum.osmotherly@gmail.com>
+
+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 <callum.osmotherly@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/YyMjQO3mhyXlMbCf@piranha
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -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),
--- /dev/null
+From bdc9b7396f7d4d6533e70fd8d5472f505b5ef58f Mon Sep 17 00:00:00 2001
+From: Callum Osmotherly <callum.osmotherly@gmail.com>
+Date: Wed, 14 Sep 2022 18:44:00 +0930
+Subject: ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5570 laptop
+
+From: Callum Osmotherly <callum.osmotherly@gmail.com>
+
+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 <callum.osmotherly@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/YyGbWM5wEoFMbW2v@piranha
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -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),
--- /dev/null
+From b16c8f229a58eaddfc58aab447253464abd3c85e Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 15 Sep 2022 17:47:24 +0200
+Subject: ALSA: hda/realtek: Re-arrange quirk table entries
+
+From: Takashi Iwai <tiwai@suse.de>
+
+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: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220915154724.31634-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 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),
--- /dev/null
+From a362bb864b8db4861977d00bd2c3222503ccc34b Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 8 Sep 2022 12:31:51 +0100
+Subject: btrfs: fix hang during unmount when stopping a space reclaim worker
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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: <TASK>
+ 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: </TASK>
+
+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 <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 8a1f1e3d1eecf9d2359a2709e276743a67e145db Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 8 Sep 2022 12:31:50 +0100
+Subject: btrfs: fix hang during unmount when stopping block group reclaim worker
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 5f56a74cc0a6d9b9f8ba89cea29cd7c4774cb2b1 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Tue, 20 Sep 2022 17:08:23 +0200
+Subject: efi: libstub: check Shim mode using MokSBStateRT
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+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: <stable@vger.kernel.org> # v4.19+
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
+Reviewed-by: Peter Jones <pjones@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Thu, 4 Aug 2022 15:39:48 +0200
+Subject: efi: x86: Wipe setup_data on pure EFI boot
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+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: <stable@vger.kernel.org> # v5.10+
+Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
+
--- /dev/null
+From 154897807050c1161cb2660e502fc0470d46b986 Mon Sep 17 00:00:00 2001
+From: Yi Liu <yi.l.liu@intel.com>
+Date: Wed, 21 Sep 2022 10:40:54 +0800
+Subject: iommu/vt-d: Check correct capability for sagaw determination
+
+From: Yi Liu <yi.l.liu@intel.com>
+
+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 <raghunathan.srinivasan@intel.com>
+Signed-off-by: Yi Liu <yi.l.liu@intel.com>
+Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Reviewed-by: Raghunathan Srinivasan <raghunathan.srinivasan@intel.com>
+Link: https://lore.kernel.org/r/20220916071212.2223869-2-yi.l.liu@intel.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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. */
--- /dev/null
+From 763679f0eeff0185fc431498849bbc1c24460875 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 22 Aug 2022 17:10:27 +0200
+Subject: media: flexcop-usb: fix endpoint type check
+
+From: Johan Hovold <johan@kernel.org>
+
+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 <oneukum@suse.com>
+Cc: stable@vger.kernel.org # 5.9
+Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20220822151027.27026-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
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
--- /dev/null
+From 14c7d905283744809e6b82efae2f490660a11cda Mon Sep 17 00:00:00 2001
+From: Gil Fine <gil.fine@intel.com>
+Date: Thu, 8 Sep 2022 13:43:20 +0300
+Subject: thunderbolt: Add support for Intel Maple Ridge single port controller
+
+From: Gil Fine <gil.fine@intel.com>
+
+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 <gil.fine@intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 91062e663b261815573ce00967b1895a99e668df Mon Sep 17 00:00:00 2001
+From: William Wu <william.wu@rock-chips.com>
+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 <william.wu@rock-chips.com>
+
+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 <stable@kernel.org>
+Reviewed-by: Sven Peter <sven@svenpeter.dev>
+Signed-off-by: William Wu <william.wu@rock-chips.com>
+Link: https://lore.kernel.org/r/20220901083446.3799754-1-william.wu@rock-chips.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
