--- /dev/null
+From 366c3223d7cb92bc1b7c3da459c1f23fef31f873 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 1 May 2022 14:42:37 +0200
+Subject: ALSA: hda/realtek: Add quirk for Dell Latitude 7520
+
+From: Gabriele Mazzotta <gabriele.mzt@gmail.com>
+
+[ Upstream commit 1efcdd9c1f34f5a6590bc9ac5471e562fb011386 ]
+
+The driver is currently using ALC269_FIXUP_DELL4_MIC_NO_PRESENCE for
+the Latitude 7520, but this fixup chain has some issues:
+
+ - The internal mic is really loud and the recorded audio is distorted
+ at "standard" audio levels.
+
+ - There are pop noises at system startup and when plugging/unplugging
+ headphone jacks.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215885
+Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
+Link: https://lore.kernel.org/r/20220501124237.4667-1-gabriele.mzt@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/pci/hda/patch_realtek.c | 43 +++++++++++++++++++++++++++++++++++
+ 1 file changed, 43 insertions(+)
+
+diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
+index e38acdbe1a3b..cc3cf65ad5b9 100644
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -6773,6 +6773,41 @@ static void alc256_fixup_mic_no_presence_and_resume(struct hda_codec *codec,
+ }
+ }
+
++static void alc_fixup_dell4_mic_no_presence_quiet(struct hda_codec *codec,
++ const struct hda_fixup *fix,
++ int action)
++{
++ struct alc_spec *spec = codec->spec;
++ struct hda_input_mux *imux = &spec->gen.input_mux;
++ int i;
++
++ alc269_fixup_limit_int_mic_boost(codec, fix, action);
++
++ switch (action) {
++ case HDA_FIXUP_ACT_PRE_PROBE:
++ /**
++ * Set the vref of pin 0x19 (Headset Mic) and pin 0x1b (Headphone Mic)
++ * to Hi-Z to avoid pop noises at startup and when plugging and
++ * unplugging headphones.
++ */
++ snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
++ snd_hda_codec_set_pin_target(codec, 0x1b, PIN_VREFHIZ);
++ break;
++ case HDA_FIXUP_ACT_PROBE:
++ /**
++ * Make the internal mic (0x12) the default input source to
++ * prevent pop noises on cold boot.
++ */
++ for (i = 0; i < imux->num_items; i++) {
++ if (spec->gen.imux_pins[i] == 0x12) {
++ spec->gen.cur_mux[0] = i;
++ break;
++ }
++ }
++ break;
++ }
++}
++
+ enum {
+ ALC269_FIXUP_GPIO2,
+ ALC269_FIXUP_SONY_VAIO,
+@@ -6814,6 +6849,7 @@ enum {
+ ALC269_FIXUP_DELL2_MIC_NO_PRESENCE,
+ ALC269_FIXUP_DELL3_MIC_NO_PRESENCE,
+ ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
++ ALC269_FIXUP_DELL4_MIC_NO_PRESENCE_QUIET,
+ ALC269_FIXUP_HEADSET_MODE,
+ ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC,
+ ALC269_FIXUP_ASPIRE_HEADSET_MIC,
+@@ -8770,6 +8806,12 @@ static const struct hda_fixup alc269_fixups[] = {
+ .chained = true,
+ .chain_id = ALC285_FIXUP_HP_MUTE_LED,
+ },
++ [ALC269_FIXUP_DELL4_MIC_NO_PRESENCE_QUIET] = {
++ .type = HDA_FIXUP_FUNC,
++ .v.func = alc_fixup_dell4_mic_no_presence_quiet,
++ .chained = true,
++ .chain_id = ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
++ },
+ };
+
+ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+@@ -8860,6 +8902,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x1028, 0x09bf, "Dell Precision", ALC233_FIXUP_ASUS_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1028, 0x0a2e, "Dell", ALC236_FIXUP_DELL_AIO_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1028, 0x0a30, "Dell", ALC236_FIXUP_DELL_AIO_HEADSET_MIC),
++ SND_PCI_QUIRK(0x1028, 0x0a38, "Dell Latitude 7520", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE_QUIET),
+ SND_PCI_QUIRK(0x1028, 0x0a58, "Dell", ALC255_FIXUP_DELL_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1028, 0x0a61, "Dell XPS 15 9510", ALC289_FIXUP_DUAL_SPK),
+ SND_PCI_QUIRK(0x1028, 0x0a62, "Dell Precision 5560", ALC289_FIXUP_DUAL_SPK),
+--
+2.35.1
+
--- /dev/null
+From 910f5a43e002e5af1b5048d7531ff5231f58a1b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 May 2022 20:07:59 -0500
+Subject: ALSA: hda/realtek: Add quirk for the Framework Laptop
+
+From: Dustin L. Howett <dustin@howett.net>
+
+[ Upstream commit 309d7363ca3d9fcdb92ff2d958be14d7e8707f68 ]
+
+Some board revisions of the Framework Laptop have an ALC295 with a
+disconnected or faulty headset mic presence detect.
+
+The "dell-headset-multi" fixup addresses this issue, but also enables an
+inoperative "Headphone Mic" input device whenever a headset is
+connected.
+
+Adding a new quirk chain specific to the Framework Laptop resolves this
+issue. The one introduced here is based on the System76 "no headphone
+mic" quirk chain.
+
+The VID:PID f111:0001 have been allocated to Framework Computer for this
+board revision.
+
+Revision history:
+- v2: Moved to a custom quirk chain to suppress the "Headphone Mic"
+ pincfg.
+
+Signed-off-by: Dustin L. Howett <dustin@howett.net>
+Link: https://lore.kernel.org/r/20220511010759.3554-1-dustin@howett.net
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/pci/hda/patch_realtek.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
+index cc3cf65ad5b9..53d1586b71ec 100644
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -7036,6 +7036,7 @@ enum {
+ ALC287_FIXUP_LEGION_16ACHG6,
+ ALC287_FIXUP_CS35L41_I2C_2,
+ ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED,
++ ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE,
+ };
+
+ static const struct hda_fixup alc269_fixups[] = {
+@@ -8812,6 +8813,15 @@ static const struct hda_fixup alc269_fixups[] = {
+ .chained = true,
+ .chain_id = ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
+ },
++ [ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = (const struct hda_pintbl[]) {
++ { 0x19, 0x02a1112c }, /* use as headset mic, without its own jack detect */
++ { }
++ },
++ .chained = true,
++ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
++ },
+ };
+
+ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+@@ -9292,6 +9302,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x8086, 0x2074, "Intel NUC 8", ALC233_FIXUP_INTEL_NUC8_DMIC),
+ SND_PCI_QUIRK(0x8086, 0x2080, "Intel NUC 8 Rugged", ALC256_FIXUP_INTEL_NUC8_RUGGED),
+ SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", ALC256_FIXUP_INTEL_NUC10),
++ SND_PCI_QUIRK(0xf111, 0x0001, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
+
+ #if 0
+ /* Below is a quirk table taken from the old code.
+--
+2.35.1
+
--- /dev/null
+From 72fefaf290d2f16a320e8977214c31a89405629f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 May 2022 19:24:44 -0500
+Subject: ALSA: usb-audio: Don't get sample rate for MCT Trigger 5 USB-to-HDMI
+
+From: Forest Crossman <cyrozap@gmail.com>
+
+[ Upstream commit d7be213849232a2accb219d537edf056d29186b4 ]
+
+This device doesn't support reading the sample rate, so we need to apply
+this quirk to avoid a 15-second delay waiting for three timeouts.
+
+Signed-off-by: Forest Crossman <cyrozap@gmail.com>
+Link: https://lore.kernel.org/r/20220504002444.114011-2-cyrozap@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/usb/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
+index ab9f3da49941..fbbe59054c3f 100644
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1822,6 +1822,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
+ QUIRK_FLAG_IGNORE_CTL_ERROR),
+ DEVICE_FLG(0x06f8, 0xd002, /* Hercules DJ Console (Macintosh Edition) */
+ QUIRK_FLAG_IGNORE_CTL_ERROR),
++ DEVICE_FLG(0x0711, 0x5800, /* MCT Trigger 5 USB-to-HDMI */
++ QUIRK_FLAG_GET_SAMPLE_RATE),
+ DEVICE_FLG(0x074d, 0x3553, /* Outlaw RR2150 (Micronas UAC3553B) */
+ QUIRK_FLAG_GET_SAMPLE_RATE),
+ DEVICE_FLG(0x08bb, 0x2702, /* LineX FM Transmitter */
+--
+2.35.1
+
--- /dev/null
+From c3714b6c5866bdfe58047614acabaa8bf5621794 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 May 2022 06:36:59 -0700
+Subject: drivers: i2c: thunderx: Allow driver to work with ACPI defined TWSI
+ controllers
+
+From: Piyush Malgujar <pmalgujar@marvell.com>
+
+[ Upstream commit 03a35bc856ddc09f2cc1f4701adecfbf3b464cb3 ]
+
+Due to i2c->adap.dev.fwnode not being set, ACPI_COMPANION() wasn't properly
+found for TWSI controllers.
+
+Signed-off-by: Szymon Balcerak <sbalcerak@marvell.com>
+Signed-off-by: Piyush Malgujar <pmalgujar@marvell.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-thunderx-pcidrv.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/i2c/busses/i2c-thunderx-pcidrv.c b/drivers/i2c/busses/i2c-thunderx-pcidrv.c
+index 12c90aa0900e..a77cd86fe75e 100644
+--- a/drivers/i2c/busses/i2c-thunderx-pcidrv.c
++++ b/drivers/i2c/busses/i2c-thunderx-pcidrv.c
+@@ -213,6 +213,7 @@ static int thunder_i2c_probe_pci(struct pci_dev *pdev,
+ i2c->adap.bus_recovery_info = &octeon_i2c_recovery_info;
+ i2c->adap.dev.parent = dev;
+ i2c->adap.dev.of_node = pdev->dev.of_node;
++ i2c->adap.dev.fwnode = dev->fwnode;
+ snprintf(i2c->adap.name, sizeof(i2c->adap.name),
+ "Cavium ThunderX i2c adapter at %s", dev_name(dev));
+ i2c_set_adapdata(&i2c->adap, i2c);
+--
+2.35.1
+
--- /dev/null
+From 807b7ad517f84c40ab93712d0390a5f0e7534d42 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Apr 2022 13:19:10 +0300
+Subject: i2c: ismt: Provide a DMA buffer for Interrupt Cause Logging
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+[ Upstream commit 17a0f3acdc6ec8b89ad40f6e22165a4beee25663 ]
+
+Before sending a MSI the hardware writes information pertinent to the
+interrupt cause to a memory location pointed by SMTICL register. This
+memory holds three double words where the least significant bit tells
+whether the interrupt cause of master/target/error is valid. The driver
+does not use this but we need to set it up because otherwise it will
+perform DMA write to the default address (0) and this will cause an
+IOMMU fault such as below:
+
+ DMAR: DRHD: handling fault status reg 2
+ DMAR: [DMA Write] Request device [00:12.0] PASID ffffffff fault addr 0
+ [fault reason 05] PTE Write access is not set
+
+To prevent this from happening, provide a proper DMA buffer for this
+that then gets mapped by the IOMMU accordingly.
+
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-ismt.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c
+index f4820fd3dc13..c01430ce103a 100644
+--- a/drivers/i2c/busses/i2c-ismt.c
++++ b/drivers/i2c/busses/i2c-ismt.c
+@@ -82,6 +82,7 @@
+
+ #define ISMT_DESC_ENTRIES 2 /* number of descriptor entries */
+ #define ISMT_MAX_RETRIES 3 /* number of SMBus retries to attempt */
++#define ISMT_LOG_ENTRIES 3 /* number of interrupt cause log entries */
+
+ /* Hardware Descriptor Constants - Control Field */
+ #define ISMT_DESC_CWRL 0x01 /* Command/Write Length */
+@@ -175,6 +176,8 @@ struct ismt_priv {
+ u8 head; /* ring buffer head pointer */
+ struct completion cmp; /* interrupt completion */
+ u8 buffer[I2C_SMBUS_BLOCK_MAX + 16]; /* temp R/W data buffer */
++ dma_addr_t log_dma;
++ u32 *log;
+ };
+
+ static const struct pci_device_id ismt_ids[] = {
+@@ -411,6 +414,9 @@ static int ismt_access(struct i2c_adapter *adap, u16 addr,
+ memset(desc, 0, sizeof(struct ismt_desc));
+ desc->tgtaddr_rw = ISMT_DESC_ADDR_RW(addr, read_write);
+
++ /* Always clear the log entries */
++ memset(priv->log, 0, ISMT_LOG_ENTRIES * sizeof(u32));
++
+ /* Initialize common control bits */
+ if (likely(pci_dev_msi_enabled(priv->pci_dev)))
+ desc->control = ISMT_DESC_INT | ISMT_DESC_FAIR;
+@@ -708,6 +714,8 @@ static void ismt_hw_init(struct ismt_priv *priv)
+ /* initialize the Master Descriptor Base Address (MDBA) */
+ writeq(priv->io_rng_dma, priv->smba + ISMT_MSTR_MDBA);
+
++ writeq(priv->log_dma, priv->smba + ISMT_GR_SMTICL);
++
+ /* initialize the Master Control Register (MCTRL) */
+ writel(ISMT_MCTRL_MEIE, priv->smba + ISMT_MSTR_MCTRL);
+
+@@ -795,6 +803,12 @@ static int ismt_dev_init(struct ismt_priv *priv)
+ priv->head = 0;
+ init_completion(&priv->cmp);
+
++ priv->log = dmam_alloc_coherent(&priv->pci_dev->dev,
++ ISMT_LOG_ENTRIES * sizeof(u32),
++ &priv->log_dma, GFP_KERNEL);
++ if (!priv->log)
++ return -ENOMEM;
++
+ return 0;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 8d0f86abafeb68287198975ef33276529179be35 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 May 2022 09:26:07 +0000
+Subject: KVM: arm64: Don't hypercall before EL2 init
+
+From: Quentin Perret <qperret@google.com>
+
+[ Upstream commit 2e40316753ee552fb598e8da8ca0d20a04e67453 ]
+
+Will reported the following splat when running with Protected KVM
+enabled:
+
+[ 2.427181] ------------[ cut here ]------------
+[ 2.427668] WARNING: CPU: 3 PID: 1 at arch/arm64/kvm/mmu.c:489 __create_hyp_private_mapping+0x118/0x1ac
+[ 2.428424] Modules linked in:
+[ 2.429040] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc2-00084-g8635adc4efc7 #1
+[ 2.429589] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
+[ 2.430286] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+[ 2.430734] pc : __create_hyp_private_mapping+0x118/0x1ac
+[ 2.431091] lr : create_hyp_exec_mappings+0x40/0x80
+[ 2.431377] sp : ffff80000803baf0
+[ 2.431597] x29: ffff80000803bb00 x28: 0000000000000000 x27: 0000000000000000
+[ 2.432156] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
+[ 2.432561] x23: ffffcd96c343b000 x22: 0000000000000000 x21: ffff80000803bb40
+[ 2.433004] x20: 0000000000000004 x19: 0000000000001800 x18: 0000000000000000
+[ 2.433343] x17: 0003e68cf7efdd70 x16: 0000000000000004 x15: fffffc81f602a2c8
+[ 2.434053] x14: ffffdf8380000000 x13: ffffcd9573200000 x12: ffffcd96c343b000
+[ 2.434401] x11: 0000000000000004 x10: ffffcd96c1738000 x9 : 0000000000000004
+[ 2.434812] x8 : ffff80000803bb40 x7 : 7f7f7f7f7f7f7f7f x6 : 544f422effff306b
+[ 2.435136] x5 : 000000008020001e x4 : ffff207d80a88c00 x3 : 0000000000000005
+[ 2.435480] x2 : 0000000000001800 x1 : 000000014f4ab800 x0 : 000000000badca11
+[ 2.436149] Call trace:
+[ 2.436600] __create_hyp_private_mapping+0x118/0x1ac
+[ 2.437576] create_hyp_exec_mappings+0x40/0x80
+[ 2.438180] kvm_init_vector_slots+0x180/0x194
+[ 2.458941] kvm_arch_init+0x80/0x274
+[ 2.459220] kvm_init+0x48/0x354
+[ 2.459416] arm_init+0x20/0x2c
+[ 2.459601] do_one_initcall+0xbc/0x238
+[ 2.459809] do_initcall_level+0x94/0xb4
+[ 2.460043] do_initcalls+0x54/0x94
+[ 2.460228] do_basic_setup+0x1c/0x28
+[ 2.460407] kernel_init_freeable+0x110/0x178
+[ 2.460610] kernel_init+0x20/0x1a0
+[ 2.460817] ret_from_fork+0x10/0x20
+[ 2.461274] ---[ end trace 0000000000000000 ]---
+
+Indeed, the Protected KVM mode promotes __create_hyp_private_mapping()
+to a hypercall as EL1 no longer has access to the hypervisor's stage-1
+page-table. However, the call from kvm_init_vector_slots() happens after
+pKVM has been initialized on the primary CPU, but before it has been
+initialized on secondaries. As such, if the KVM initcall procedure is
+migrated from one CPU to another in this window, the hypercall may end up
+running on a CPU for which EL2 has not been initialized.
+
+Fortunately, the pKVM hypervisor doesn't rely on the host to re-map the
+vectors in the private range, so the hypercall in question is in fact
+superfluous. Skip it when pKVM is enabled.
+
+Reported-by: Will Deacon <will@kernel.org>
+Signed-off-by: Quentin Perret <qperret@google.com>
+[maz: simplified the checks slightly]
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20220513092607.35233-1-qperret@google.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/kvm/arm.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
+index 25d8aff273a1..4dd5f3b08aaa 100644
+--- a/arch/arm64/kvm/arm.c
++++ b/arch/arm64/kvm/arm.c
+@@ -1496,7 +1496,8 @@ static int kvm_init_vector_slots(void)
+ base = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs));
+ kvm_init_vector_slot(base, HYP_VECTOR_SPECTRE_DIRECT);
+
+- if (kvm_system_needs_idmapped_vectors() && !has_vhe()) {
++ if (kvm_system_needs_idmapped_vectors() &&
++ !is_protected_kvm_enabled()) {
+ err = create_hyp_exec_mappings(__pa_symbol(__bp_harden_hyp_vecs),
+ __BP_HARDEN_HYP_VECS_SZ, &base);
+ if (err)
+--
+2.35.1
+
--- /dev/null
+From b11e298f6a5826ca57f73a0925a604827d66c015 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 May 2022 08:32:18 +0200
+Subject: net: af_key: check encryption module availability consistency
+
+From: Thomas Bartschies <thomas.bartschies@cvk.de>
+
+[ Upstream commit 015c44d7bff3f44d569716117becd570c179ca32 ]
+
+Since the recent introduction supporting the SM3 and SM4 hash algos for IPsec, the kernel
+produces invalid pfkey acquire messages, when these encryption modules are disabled. This
+happens because the availability of the algos wasn't checked in all necessary functions.
+This patch adds these checks.
+
+Signed-off-by: Thomas Bartschies <thomas.bartschies@cvk.de>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/key/af_key.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/net/key/af_key.c b/net/key/af_key.c
+index 92e9d75dba2f..339d95df19d3 100644
+--- a/net/key/af_key.c
++++ b/net/key/af_key.c
+@@ -2900,7 +2900,7 @@ static int count_ah_combs(const struct xfrm_tmpl *t)
+ break;
+ if (!aalg->pfkey_supported)
+ continue;
+- if (aalg_tmpl_set(t, aalg))
++ if (aalg_tmpl_set(t, aalg) && aalg->available)
+ sz += sizeof(struct sadb_comb);
+ }
+ return sz + sizeof(struct sadb_prop);
+@@ -2918,7 +2918,7 @@ static int count_esp_combs(const struct xfrm_tmpl *t)
+ if (!ealg->pfkey_supported)
+ continue;
+
+- if (!(ealg_tmpl_set(t, ealg)))
++ if (!(ealg_tmpl_set(t, ealg) && ealg->available))
+ continue;
+
+ for (k = 1; ; k++) {
+@@ -2929,7 +2929,7 @@ static int count_esp_combs(const struct xfrm_tmpl *t)
+ if (!aalg->pfkey_supported)
+ continue;
+
+- if (aalg_tmpl_set(t, aalg))
++ if (aalg_tmpl_set(t, aalg) && aalg->available)
+ sz += sizeof(struct sadb_comb);
+ }
+ }
+--
+2.35.1
+
--- /dev/null
+From 58ed827287d05b81245b4affa545abaa67da4d8c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 May 2022 18:52:17 +0930
+Subject: net: ftgmac100: Disable hardware checksum on AST2600
+
+From: Joel Stanley <joel@jms.id.au>
+
+[ Upstream commit 6fd45e79e8b93b8d22fb8fe22c32fbad7e9190bd ]
+
+The AST2600 when using the i210 NIC over NC-SI has been observed to
+produce incorrect checksum results with specific MTU values. This was
+first observed when sending data across a long distance set of networks.
+
+On a local network, the following test was performed using a 1MB file of
+random data.
+
+On the receiver run this script:
+
+ #!/bin/bash
+ while [ 1 ]; do
+ # Zero the stats
+ nstat -r > /dev/null
+ nc -l 9899 > test-file
+ # Check for checksum errors
+ TcpInCsumErrors=$(nstat | grep TcpInCsumErrors)
+ if [ -z "$TcpInCsumErrors" ]; then
+ echo No TcpInCsumErrors
+ else
+ echo TcpInCsumErrors = $TcpInCsumErrors
+ fi
+ done
+
+On an AST2600 system:
+
+ # nc <IP of receiver host> 9899 < test-file
+
+The test was repeated with various MTU values:
+
+ # ip link set mtu 1410 dev eth0
+
+The observed results:
+
+ 1500 - good
+ 1434 - bad
+ 1400 - good
+ 1410 - bad
+ 1420 - good
+
+The test was repeated after disabling tx checksumming:
+
+ # ethtool -K eth0 tx-checksumming off
+
+And all MTU values tested resulted in transfers without error.
+
+An issue with the driver cannot be ruled out, however there has been no
+bug discovered so far.
+
+David has done the work to take the original bug report of slow data
+transfer between long distance connections and triaged it down to this
+test case.
+
+The vendor suspects this this is a hardware issue when using NC-SI. The
+fixes line refers to the patch that introduced AST2600 support.
+
+Reported-by: David Wilder <wilder@us.ibm.com>
+Reviewed-by: Dylan Hung <dylan_hung@aspeedtech.com>
+Signed-off-by: Joel Stanley <joel@jms.id.au>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
+index caf48023f8ea..5231818943c6 100644
+--- a/drivers/net/ethernet/faraday/ftgmac100.c
++++ b/drivers/net/ethernet/faraday/ftgmac100.c
+@@ -1928,6 +1928,11 @@ static int ftgmac100_probe(struct platform_device *pdev)
+ /* AST2400 doesn't have working HW checksum generation */
+ if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac")))
+ netdev->hw_features &= ~NETIF_F_HW_CSUM;
++
++ /* AST2600 tx checksum with NCSI is broken */
++ if (priv->use_ncsi && of_device_is_compatible(np, "aspeed,ast2600-mac"))
++ netdev->hw_features &= ~NETIF_F_HW_CSUM;
++
+ if (np && of_get_property(np, "no-hw-checksum", NULL))
+ netdev->hw_features &= ~(NETIF_F_HW_CSUM | NETIF_F_RXCSUM);
+ netdev->features |= netdev->hw_features;
+--
+2.35.1
+
--- /dev/null
+From 952a4636c1c94e7a3f880d2525b1bc781a9d9b21 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 May 2022 18:53:21 +0800
+Subject: nfc: pn533: Fix buggy cleanup order
+
+From: Lin Ma <linma@zju.edu.cn>
+
+[ Upstream commit b8cedb7093b2d1394cae9b86494cba4b62d3a30a ]
+
+When removing the pn533 device (i2c or USB), there is a logic error. The
+original code first cancels the worker (flush_delayed_work) and then
+destroys the workqueue (destroy_workqueue), leaving the timer the last
+one to be deleted (del_timer). This result in a possible race condition
+in a multi-core preempt-able kernel. That is, if the cleanup
+(pn53x_common_clean) is concurrently run with the timer handler
+(pn533_listen_mode_timer), the timer can queue the poll_work to the
+already destroyed workqueue, causing use-after-free.
+
+This patch reorder the cleanup: it uses the del_timer_sync to make sure
+the handler is finished before the routine will destroy the workqueue.
+Note that the timer cannot be activated by the worker again.
+
+static void pn533_wq_poll(struct work_struct *work)
+...
+ rc = pn533_send_poll_frame(dev);
+ if (rc)
+ return;
+
+ if (cur_mod->len == 0 && dev->poll_mod_count > 1)
+ mod_timer(&dev->listen_timer, ...);
+
+That is, the mod_timer can be called only when pn533_send_poll_frame()
+returns no error, which is impossible because the device is detaching
+and the lower driver should return ENODEV code.
+
+Signed-off-by: Lin Ma <linma@zju.edu.cn>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nfc/pn533/pn533.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
+index a491db46e3bd..d9f6367b9993 100644
+--- a/drivers/nfc/pn533/pn533.c
++++ b/drivers/nfc/pn533/pn533.c
+@@ -2787,13 +2787,14 @@ void pn53x_common_clean(struct pn533 *priv)
+ {
+ struct pn533_cmd *cmd, *n;
+
++ /* delete the timer before cleanup the worker */
++ del_timer_sync(&priv->listen_timer);
++
+ flush_delayed_work(&priv->poll_work);
+ destroy_workqueue(priv->wq);
+
+ skb_queue_purge(&priv->resp_q);
+
+- del_timer(&priv->listen_timer);
+-
+ list_for_each_entry_safe(cmd, n, &priv->cmd_queue, queue) {
+ list_del(&cmd->queue);
+ kfree(cmd);
+--
+2.35.1
+
--- /dev/null
+From b47d04f75f942987a7d88694444c23265040de16 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 May 2022 02:13:40 -0400
+Subject: percpu_ref_init(): clean ->percpu_count_ref on failure
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+[ Upstream commit a91714312eb16f9ecd1f7f8b3efe1380075f28d4 ]
+
+That way percpu_ref_exit() is safe after failing percpu_ref_init().
+At least one user (cgroup_create()) had a double-free that way;
+there might be other similar bugs. Easier to fix in percpu_ref_init(),
+rather than playing whack-a-mole in sloppy users...
+
+Usual symptoms look like a messed refcounting in one of subsystems
+that use percpu allocations (might be percpu-refcount, might be
+something else). Having refcounts for two different objects share
+memory is Not Nice(tm)...
+
+Reported-by: syzbot+5b1e53987f858500ec00@syzkaller.appspotmail.com
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/percpu-refcount.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
+index af9302141bcf..e5c5315da274 100644
+--- a/lib/percpu-refcount.c
++++ b/lib/percpu-refcount.c
+@@ -76,6 +76,7 @@ int percpu_ref_init(struct percpu_ref *ref, percpu_ref_func_t *release,
+ data = kzalloc(sizeof(*ref->data), gfp);
+ if (!data) {
+ free_percpu((void __percpu *)ref->percpu_count_ptr);
++ ref->percpu_count_ptr = 0;
+ return -ENOMEM;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From afc6170839c560eaac8621de60cb3f4870d07188 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 May 2022 19:59:04 +0800
+Subject: pinctrl: sunxi: fix f1c100s uart2 function
+
+From: IotaHydrae <writeforever@foxmail.com>
+
+[ Upstream commit fa8785e5931367e2b43f2c507f26bcf3e281c0ca ]
+
+Change suniv f1c100s pinctrl,PD14 multiplexing function lvds1 to uart2
+
+When the pin PD13 and PD14 is setting up to uart2 function in dts,
+there's an error occurred:
+1c20800.pinctrl: unsupported function uart2 on pin PD14
+
+Because 'uart2' is not any one multiplexing option of PD14,
+and pinctrl don't know how to configure it.
+
+So change the pin PD14 lvds1 function to uart2.
+
+Signed-off-by: IotaHydrae <writeforever@foxmail.com>
+Reviewed-by: Andre Przywara <andre.przywara@arm.com>
+Link: https://lore.kernel.org/r/tencent_70C1308DDA794C81CAEF389049055BACEC09@qq.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c b/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c
+index 2801ca706273..68a5b627fb9b 100644
+--- a/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c
++++ b/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c
+@@ -204,7 +204,7 @@ static const struct sunxi_desc_pin suniv_f1c100s_pins[] = {
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D20 */
+- SUNXI_FUNCTION(0x3, "lvds1"), /* RX */
++ SUNXI_FUNCTION(0x3, "uart2"), /* RX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+--
+2.35.1
+
random-check-for-signals-after-page-of-pool-writes.patch
acpi-sysfs-fix-bert-error-region-memory-mapping.patch
alsa-ctxfi-add-sb046x-pci-id.patch
+alsa-usb-audio-don-t-get-sample-rate-for-mct-trigger.patch
+alsa-hda-realtek-add-quirk-for-dell-latitude-7520.patch
+alsa-hda-realtek-add-quirk-for-the-framework-laptop.patch
+pinctrl-sunxi-fix-f1c100s-uart2-function.patch
+kvm-arm64-don-t-hypercall-before-el2-init.patch
+percpu_ref_init-clean-percpu_count_ref-on-failure.patch
+net-af_key-check-encryption-module-availability-cons.patch
+nfc-pn533-fix-buggy-cleanup-order.patch
+net-ftgmac100-disable-hardware-checksum-on-ast2600.patch
+i2c-ismt-provide-a-dma-buffer-for-interrupt-cause-lo.patch
+drivers-i2c-thunderx-allow-driver-to-work-with-acpi-.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
