--- /dev/null
+From 4639c5021029d49fd2f97fa8d74731f167f98919 Mon Sep 17 00:00:00 2001
+From: bo liu <bo.liu@senarytech.com>
+Date: Mon, 5 Feb 2024 09:38:02 +0800
+Subject: ALSA: hda/conexant: Add quirk for SWS JS201D
+
+From: bo liu <bo.liu@senarytech.com>
+
+commit 4639c5021029d49fd2f97fa8d74731f167f98919 upstream.
+
+The SWS JS201D need a different pinconfig from windows driver.
+Add a quirk to use a specific pinconfig to SWS JS201D.
+
+Signed-off-by: bo liu <bo.liu@senarytech.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240205013802.51907-1-bo.liu@senarytech.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_conexant.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -344,6 +344,7 @@ enum {
+ CXT_FIXUP_HP_ZBOOK_MUTE_LED,
+ CXT_FIXUP_HEADSET_MIC,
+ CXT_FIXUP_HP_MIC_NO_PRESENCE,
++ CXT_PINCFG_SWS_JS201D,
+ };
+
+ /* for hda_fixup_thinkpad_acpi() */
+@@ -841,6 +842,17 @@ static const struct hda_pintbl cxt_pincf
+ {}
+ };
+
++/* SuoWoSi/South-holding JS201D with sn6140 */
++static const struct hda_pintbl cxt_pincfg_sws_js201d[] = {
++ { 0x16, 0x03211040 }, /* hp out */
++ { 0x17, 0x91170110 }, /* SPK/Class_D */
++ { 0x18, 0x95a70130 }, /* Internal mic */
++ { 0x19, 0x03a11020 }, /* Headset Mic */
++ { 0x1a, 0x40f001f0 }, /* Not used */
++ { 0x21, 0x40f001f0 }, /* Not used */
++ {}
++};
++
+ static const struct hda_fixup cxt_fixups[] = {
+ [CXT_PINCFG_LENOVO_X200] = {
+ .type = HDA_FIXUP_PINS,
+@@ -996,6 +1008,10 @@ static const struct hda_fixup cxt_fixups
+ .chained = true,
+ .chain_id = CXT_FIXUP_HEADSET_MIC,
+ },
++ [CXT_PINCFG_SWS_JS201D] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = cxt_pincfg_sws_js201d,
++ },
+ };
+
+ static const struct snd_pci_quirk cxt5045_fixups[] = {
+@@ -1069,6 +1085,7 @@ static const struct snd_pci_quirk cxt506
+ SND_PCI_QUIRK(0x103c, 0x8457, "HP Z2 G4 mini", CXT_FIXUP_HP_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x103c, 0x8458, "HP Z2 G4 mini premium", CXT_FIXUP_HP_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1043, 0x138d, "Asus", CXT_FIXUP_HEADPHONE_MIC_PIN),
++ SND_PCI_QUIRK(0x14f1, 0x0265, "SWS JS201D", CXT_PINCFG_SWS_JS201D),
+ SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT_FIXUP_OLPC_XO),
+ SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400", CXT_PINCFG_LENOVO_TP410),
+ SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo T410", CXT_PINCFG_LENOVO_TP410),
+@@ -1109,6 +1126,7 @@ static const struct hda_model_fixup cxt5
+ { .id = CXT_FIXUP_HP_ZBOOK_MUTE_LED, .name = "hp-zbook-mute-led" },
+ { .id = CXT_FIXUP_HP_MIC_NO_PRESENCE, .name = "hp-mic-fix" },
+ { .id = CXT_PINCFG_LENOVO_NOTEBOOK, .name = "lenovo-20149" },
++ { .id = CXT_PINCFG_SWS_JS201D, .name = "sws-js201d" },
+ {}
+ };
+
--- /dev/null
+From fddab35fd064414c677e9488c4fb3a1f67725d37 Mon Sep 17 00:00:00 2001
+From: Shuming Fan <shumingf@realtek.com>
+Date: Mon, 5 Feb 2024 15:22:52 +0800
+Subject: ALSA: hda/realtek: add IDs for Dell dual spk platform
+
+From: Shuming Fan <shumingf@realtek.com>
+
+commit fddab35fd064414c677e9488c4fb3a1f67725d37 upstream.
+
+This patch adds another two IDs for the Dell dual speaker platform.
+
+Signed-off-by: Shuming Fan <shumingf@realtek.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240205072252.3791500-1-shumingf@realtek.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9631,7 +9631,9 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1028, 0x0b71, "Dell Inspiron 16 Plus 7620", ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS),
+ SND_PCI_QUIRK(0x1028, 0x0beb, "Dell XPS 15 9530 (2023)", ALC289_FIXUP_DELL_CS35L41_SPI_2),
+ SND_PCI_QUIRK(0x1028, 0x0c03, "Dell Precision 5340", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE),
++ SND_PCI_QUIRK(0x1028, 0x0c0b, "Dell Oasis 14 RPL-P", ALC289_FIXUP_RTK_AMP_DUAL_SPK),
+ SND_PCI_QUIRK(0x1028, 0x0c0d, "Dell Oasis", ALC289_FIXUP_RTK_AMP_DUAL_SPK),
++ SND_PCI_QUIRK(0x1028, 0x0c0e, "Dell Oasis 16", ALC289_FIXUP_RTK_AMP_DUAL_SPK),
+ SND_PCI_QUIRK(0x1028, 0x0c19, "Dell Precision 3340", ALC236_FIXUP_DELL_DUAL_CODECS),
+ SND_PCI_QUIRK(0x1028, 0x0c1a, "Dell Precision 3340", ALC236_FIXUP_DELL_DUAL_CODECS),
+ SND_PCI_QUIRK(0x1028, 0x0c1b, "Dell Precision 3440", ALC236_FIXUP_DELL_DUAL_CODECS),
--- /dev/null
+From 32f03f4002c5df837fb920eb23fcd2f4af9b0b23 Mon Sep 17 00:00:00 2001
+From: Eniac Zhang <eniac-xw.zhang@hp.com>
+Date: Thu, 15 Feb 2024 15:49:22 +0000
+Subject: ALSA: hda/realtek: fix mute/micmute LED For HP mt645
+
+From: Eniac Zhang <eniac-xw.zhang@hp.com>
+
+commit 32f03f4002c5df837fb920eb23fcd2f4af9b0b23 upstream.
+
+The HP mt645 G7 Thin Client uses an ALC236 codec and needs the
+ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make the mute and
+micmute LEDs work.
+
+There are two variants of the USB-C PD chip on this device. Each uses
+a different BIOS and board ID, hence the two entries.
+
+Signed-off-by: Eniac Zhang <eniac-xw.zhang@hp.com>
+Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240215154922.778394-1-alexandru.gagniuc@hp.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9821,6 +9821,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x8abb, "HP ZBook Firefly 14 G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8ad1, "HP EliteBook 840 14 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8ad2, "HP EliteBook 860 16 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x8b0f, "HP Elite mt645 G7 Mobile Thin Client U81", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b2f, "HP 255 15.6 inch G10 Notebook PC", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
+ SND_PCI_QUIRK(0x103c, 0x8b42, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8b43, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+@@ -9828,6 +9829,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x8b45, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8b46, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8b47, "HP", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x8b59, "HP Elite mt645 G7 Mobile Thin Client U89", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b5d, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b5e, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8b63, "HP Elite Dragonfly 13.5 inch G4", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED),
--- /dev/null
+From 94b38b895dec8c0ef093140a141e191b60ff614c Mon Sep 17 00:00:00 2001
+From: Zhikai Zhai <zhikai.zhai@amd.com>
+Date: Mon, 29 Jan 2024 17:02:18 +0800
+Subject: drm/amd/display: Add align done check
+
+From: Zhikai Zhai <zhikai.zhai@amd.com>
+
+commit 94b38b895dec8c0ef093140a141e191b60ff614c upstream.
+
+[WHY]
+We Double-check link status if training successful,
+but miss the lane align status.
+
+[HOW]
+Add the lane align status check
+
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
+Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Zhikai Zhai <zhikai.zhai@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
++++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_training.c
+@@ -517,6 +517,7 @@ enum link_training_result dp_check_link_
+ {
+ enum link_training_result status = LINK_TRAINING_SUCCESS;
+ union lane_status lane_status;
++ union lane_align_status_updated dpcd_lane_status_updated;
+ uint8_t dpcd_buf[6] = {0};
+ uint32_t lane;
+
+@@ -532,10 +533,12 @@ enum link_training_result dp_check_link_
+ * check lanes status
+ */
+ lane_status.raw = dp_get_nibble_at_index(&dpcd_buf[2], lane);
++ dpcd_lane_status_updated.raw = dpcd_buf[4];
+
+ if (!lane_status.bits.CHANNEL_EQ_DONE_0 ||
+ !lane_status.bits.CR_DONE_0 ||
+- !lane_status.bits.SYMBOL_LOCKED_0) {
++ !lane_status.bits.SYMBOL_LOCKED_0 ||
++ !dp_is_interlane_aligned(dpcd_lane_status_updated)) {
+ /* if one of the channel equalization, clock
+ * recovery or symbol lock is dropped
+ * consider it as (link has been
--- /dev/null
+From e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57 Mon Sep 17 00:00:00 2001
+From: Fangzhi Zuo <jerry.zuo@amd.com>
+Date: Mon, 22 Jan 2024 13:43:46 -0500
+Subject: drm/amd/display: Fix MST Null Ptr for RV
+
+From: Fangzhi Zuo <jerry.zuo@amd.com>
+
+commit e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57 upstream.
+
+The change try to fix below error specific to RV platform:
+
+BUG: kernel NULL pointer dereference, address: 0000000000000008
+PGD 0 P4D 0
+Oops: 0000 [#1] PREEMPT SMP NOPTI
+CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
+Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
+RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
+Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
+RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
+RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
+RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
+RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
+R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
+R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
+FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
+Call Trace:
+ <TASK>
+ ? __die+0x23/0x70
+ ? page_fault_oops+0x171/0x4e0
+ ? plist_add+0xbe/0x100
+ ? exc_page_fault+0x7c/0x180
+ ? asm_exc_page_fault+0x26/0x30
+ ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
+ ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
+ compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
+ ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
+ compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
+ amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
+ drm_atomic_check_only+0x5c5/0xa40
+ drm_mode_atomic_ioctl+0x76e/0xbc0
+ ? _copy_to_user+0x25/0x30
+ ? drm_ioctl+0x296/0x4b0
+ ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
+ drm_ioctl_kernel+0xcd/0x170
+ drm_ioctl+0x26d/0x4b0
+ ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
+ amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
+ __x64_sys_ioctl+0x94/0xd0
+ do_syscall_64+0x60/0x90
+ ? do_syscall_64+0x6c/0x90
+ entry_SYSCALL_64_after_hwframe+0x72/0xdc
+RIP: 0033:0x7f4dad17f76f
+Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c>
+RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f
+RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b
+RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003
+R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc
+R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0
+ </TASK>
+Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep >
+ typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas>
+CR2: 0000000000000008
+---[ end trace 0000000000000000 ]---
+RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
+Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
+RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
+RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
+RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
+RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
+R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
+R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
+FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
+
+With a second DP monitor connected, drm_atomic_state in dm atomic check
+sequence does not include the connector state for the old/existing/first
+DP monitor. In such case, dsc determination policy would hit a null ptr
+when it tries to iterate the old/existing stream that does not have a
+valid connector state attached to it. When that happens, dm atomic check
+should call drm_atomic_get_connector_state for a new connector state.
+Existing dm has already done that, except for RV due to it does not have
+official support of dsc where .num_dsc is not defined in dcn10 resource
+cap, that prevent from getting drm_atomic_get_connector_state called.
+So, skip dsc determination policy for ASICs that don't have DSC support.
+
+Cc: stable@vger.kernel.org # 6.1+
+Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2314
+Reviewed-by: Wayne Lin <wayne.lin@amd.com>
+Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
+Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -10358,11 +10358,13 @@ static int amdgpu_dm_atomic_check(struct
+ goto fail;
+ }
+
+- ret = compute_mst_dsc_configs_for_state(state, dm_state->context, vars);
+- if (ret) {
+- DRM_DEBUG_DRIVER("compute_mst_dsc_configs_for_state() failed\n");
+- ret = -EINVAL;
+- goto fail;
++ if (dc_resource_is_dsc_encoding_supported(dc)) {
++ ret = compute_mst_dsc_configs_for_state(state, dm_state->context, vars);
++ if (ret) {
++ DRM_DEBUG_DRIVER("compute_mst_dsc_configs_for_state() failed\n");
++ ret = -EINVAL;
++ goto fail;
++ }
+ }
+
+ ret = dm_update_mst_vcpi_slots_for_dsc(state, dm_state->context, vars);
--- /dev/null
+From e63e35f0164c43fbc1adb481d6604f253b9f9667 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Mon, 5 Feb 2024 14:54:05 -0700
+Subject: drm/amd/display: Increase frame-larger-than for all display_mode_vba files
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit e63e35f0164c43fbc1adb481d6604f253b9f9667 upstream.
+
+After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y
+and CONFIG_WERROR=y enabled) has a few new instances of
+-Wframe-larger-than for the mode support and system configuration
+functions:
+
+ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack frame size (2144) exceeds limit (2048) in 'dml20v2_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
+ 3393 | void dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
+ | ^
+ 1 error generated.
+
+ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:3520:6: error: stack frame size (2192) exceeds limit (2048) in 'dml21_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
+ 3520 | void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
+ | ^
+ 1 error generated.
+
+ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame size (2128) exceeds limit (2048) in 'dml20_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
+ 3286 | void dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
+ | ^
+ 1 error generated.
+
+Without the sanitizers enabled, there are no warnings.
+
+This was the catalyst for commit 6740ec97bcdb ("drm/amd/display:
+Increase frame warning limit with KASAN or KCSAN in dml2") and that same
+change was made to dml in commit 5b750b22530f ("drm/amd/display:
+Increase frame warning limit with KASAN or KCSAN in dml") but the
+frame_warn_flag variable was not applied to all files. Do so now to
+clear up the warnings and make all these files consistent.
+
+Cc: stable@vger.kernel.org
+Closes: https://github.com/ClangBuiltLinux/linux/issue/1990
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dml/Makefile | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
++++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
+@@ -72,11 +72,11 @@ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode
+ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags)
+-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
+-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags)
+-CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) $(frame_warn_flag)
+ CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := $(dml_ccflags)
--- /dev/null
+From deb110292180cd501f6fde2a0178d65fcbcabb0c Mon Sep 17 00:00:00 2001
+From: Tom Chung <chiahsuan.chung@amd.com>
+Date: Tue, 30 Jan 2024 15:34:08 +0800
+Subject: drm/amd/display: Preserve original aspect ratio in create stream
+
+From: Tom Chung <chiahsuan.chung@amd.com>
+
+commit deb110292180cd501f6fde2a0178d65fcbcabb0c upstream.
+
+[Why]
+The original picture aspect ratio in mode struct may have chance be
+overwritten with wrong aspect ratio data in create_stream_for_sink().
+It will create a different VIC output and cause HDMI compliance test
+failed.
+
+[How]
+Preserve the original picture aspect ratio data during create the
+stream.
+
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Tom Chung <chiahsuan.chung@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+@@ -6072,7 +6072,9 @@ create_stream_for_sink(struct amdgpu_dm_
+ if (recalculate_timing) {
+ freesync_mode = get_highest_refresh_rate_mode(aconnector, false);
+ drm_mode_copy(&saved_mode, &mode);
++ saved_mode.picture_aspect_ratio = mode.picture_aspect_ratio;
+ drm_mode_copy(&mode, freesync_mode);
++ mode.picture_aspect_ratio = saved_mode.picture_aspect_ratio;
+ } else {
+ decide_crtc_timing_for_drm_display_mode(
+ &mode, preferred_mode, scale);
--- /dev/null
+From 2f542421a47e8246e9b7d2c6508fe3a6e6c63078 Mon Sep 17 00:00:00 2001
+From: Thong <thong.thai@amd.com>
+Date: Tue, 6 Feb 2024 18:05:16 -0500
+Subject: drm/amdgpu/soc21: update VCN 4 max HEVC encoding resolution
+
+From: Thong <thong.thai@amd.com>
+
+commit 2f542421a47e8246e9b7d2c6508fe3a6e6c63078 upstream.
+
+Update the maximum resolution reported for HEVC encoding on VCN 4
+devices to reflect its 8K encoding capability.
+
+Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3159
+Signed-off-by: Thong <thong.thai@amd.com>
+Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/soc21.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/soc21.c
++++ b/drivers/gpu/drm/amd/amdgpu/soc21.c
+@@ -50,13 +50,13 @@ static const struct amd_ip_funcs soc21_c
+ /* SOC21 */
+ static const struct amdgpu_video_codec_info vcn_4_0_0_video_codecs_encode_array_vcn0[] = {
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4_AVC, 4096, 2304, 0)},
+- {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 4096, 2304, 0)},
++ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 8192, 4352, 0)},
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_AV1, 8192, 4352, 0)},
+ };
+
+ static const struct amdgpu_video_codec_info vcn_4_0_0_video_codecs_encode_array_vcn1[] = {
+ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4_AVC, 4096, 2304, 0)},
+- {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 4096, 2304, 0)},
++ {codec_info_build(AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_HEVC, 8192, 4352, 0)},
+ };
+
+ static const struct amdgpu_video_codecs vcn_4_0_0_video_codecs_encode_vcn0 = {
--- /dev/null
+From 8c7bfd8262319fd3f127a5380f593ea76f1b88a2 Mon Sep 17 00:00:00 2001
+From: Rob Clark <robdclark@chromium.org>
+Date: Tue, 13 Feb 2024 09:23:40 -0800
+Subject: drm/msm: Wire up tlb ops
+
+From: Rob Clark <robdclark@chromium.org>
+
+commit 8c7bfd8262319fd3f127a5380f593ea76f1b88a2 upstream.
+
+The brute force iommu_flush_iotlb_all() was good enough for unmap, but
+in some cases a map operation could require removing a table pte entry
+to replace with a block entry. This also requires tlb invalidation.
+Missing this was resulting an obscure iova fault on what should be a
+valid buffer address.
+
+Thanks to Robin Murphy for helping me understand the cause of the fault.
+
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: stable@vger.kernel.org
+Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
+Signed-off-by: Rob Clark <robdclark@chromium.org>
+Patchwork: https://patchwork.freedesktop.org/patch/578117/
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/msm/msm_iommu.c | 32 +++++++++++++++++++++++++++++---
+ 1 file changed, 29 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/msm/msm_iommu.c
++++ b/drivers/gpu/drm/msm/msm_iommu.c
+@@ -21,6 +21,8 @@ struct msm_iommu_pagetable {
+ struct msm_mmu base;
+ struct msm_mmu *parent;
+ struct io_pgtable_ops *pgtbl_ops;
++ const struct iommu_flush_ops *tlb;
++ struct device *iommu_dev;
+ unsigned long pgsize_bitmap; /* Bitmap of page sizes in use */
+ phys_addr_t ttbr;
+ u32 asid;
+@@ -201,11 +203,33 @@ static const struct msm_mmu_funcs pageta
+
+ static void msm_iommu_tlb_flush_all(void *cookie)
+ {
++ struct msm_iommu_pagetable *pagetable = cookie;
++ struct adreno_smmu_priv *adreno_smmu;
++
++ if (!pm_runtime_get_if_in_use(pagetable->iommu_dev))
++ return;
++
++ adreno_smmu = dev_get_drvdata(pagetable->parent->dev);
++
++ pagetable->tlb->tlb_flush_all((void *)adreno_smmu->cookie);
++
++ pm_runtime_put_autosuspend(pagetable->iommu_dev);
+ }
+
+ static void msm_iommu_tlb_flush_walk(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+ {
++ struct msm_iommu_pagetable *pagetable = cookie;
++ struct adreno_smmu_priv *adreno_smmu;
++
++ if (!pm_runtime_get_if_in_use(pagetable->iommu_dev))
++ return;
++
++ adreno_smmu = dev_get_drvdata(pagetable->parent->dev);
++
++ pagetable->tlb->tlb_flush_walk(iova, size, granule, (void *)adreno_smmu->cookie);
++
++ pm_runtime_put_autosuspend(pagetable->iommu_dev);
+ }
+
+ static void msm_iommu_tlb_add_page(struct iommu_iotlb_gather *gather,
+@@ -213,7 +237,7 @@ static void msm_iommu_tlb_add_page(struc
+ {
+ }
+
+-static const struct iommu_flush_ops null_tlb_ops = {
++static const struct iommu_flush_ops tlb_ops = {
+ .tlb_flush_all = msm_iommu_tlb_flush_all,
+ .tlb_flush_walk = msm_iommu_tlb_flush_walk,
+ .tlb_add_page = msm_iommu_tlb_add_page,
+@@ -254,10 +278,10 @@ struct msm_mmu *msm_iommu_pagetable_crea
+
+ /* The incoming cfg will have the TTBR1 quirk enabled */
+ ttbr0_cfg.quirks &= ~IO_PGTABLE_QUIRK_ARM_TTBR1;
+- ttbr0_cfg.tlb = &null_tlb_ops;
++ ttbr0_cfg.tlb = &tlb_ops;
+
+ pagetable->pgtbl_ops = alloc_io_pgtable_ops(ARM_64_LPAE_S1,
+- &ttbr0_cfg, iommu->domain);
++ &ttbr0_cfg, pagetable);
+
+ if (!pagetable->pgtbl_ops) {
+ kfree(pagetable);
+@@ -279,6 +303,8 @@ struct msm_mmu *msm_iommu_pagetable_crea
+
+ /* Needed later for TLB flush */
+ pagetable->parent = parent;
++ pagetable->tlb = ttbr1_cfg->tlb;
++ pagetable->iommu_dev = ttbr1_cfg->iommu_dev;
+ pagetable->pgsize_bitmap = ttbr0_cfg.pgsize_bitmap;
+ pagetable->ttbr = ttbr0_cfg.arm_lpae_s1_cfg.ttbr;
+
--- /dev/null
+From b671cd3d456315f63171a670769356a196cf7fd0 Mon Sep 17 00:00:00 2001
+From: Philip Yang <Philip.Yang@amd.com>
+Date: Mon, 21 Aug 2023 16:02:01 -0400
+Subject: drm/prime: Support page array >= 4GB
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Philip Yang <Philip.Yang@amd.com>
+
+commit b671cd3d456315f63171a670769356a196cf7fd0 upstream.
+
+Without unsigned long typecast, the size is passed in as zero if page
+array size >= 4GB, nr_pages >= 0x100000, then sg list converted will
+have the first and the last chunk lost.
+
+Signed-off-by: Philip Yang <Philip.Yang@amd.com>
+Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230821200201.24685-1-Philip.Yang@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_prime.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_prime.c
++++ b/drivers/gpu/drm/drm_prime.c
+@@ -820,7 +820,7 @@ struct sg_table *drm_prime_pages_to_sg(s
+ if (max_segment == 0)
+ max_segment = UINT_MAX;
+ err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0,
+- nr_pages << PAGE_SHIFT,
++ (unsigned long)nr_pages << PAGE_SHIFT,
+ max_segment, GFP_KERNEL);
+ if (err) {
+ kfree(sg);
--- /dev/null
+From a8b9cf62ade1bf17261a979fc97e40c2d7842353 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Wed, 10 Jan 2024 09:13:06 +0900
+Subject: ftrace: Fix DIRECT_CALLS to use SAVE_REGS by default
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit a8b9cf62ade1bf17261a979fc97e40c2d7842353 upstream.
+
+The commit 60c8971899f3 ("ftrace: Make DIRECT_CALLS work WITH_ARGS
+and !WITH_REGS") changed DIRECT_CALLS to use SAVE_ARGS when there
+are multiple ftrace_ops at the same function, but since the x86 only
+support to jump to direct_call from ftrace_regs_caller, when we set
+the function tracer on the same target function on x86, ftrace-direct
+does not work as below (this actually works on arm64.)
+
+At first, insmod ftrace-direct.ko to put a direct_call on
+'wake_up_process()'.
+
+ # insmod kernel/samples/ftrace/ftrace-direct.ko
+ # less trace
+...
+ <idle>-0 [006] ..s1. 564.686958: my_direct_func: waking up rcu_preempt-17
+ <idle>-0 [007] ..s1. 564.687836: my_direct_func: waking up kcompactd0-63
+ <idle>-0 [006] ..s1. 564.690926: my_direct_func: waking up rcu_preempt-17
+ <idle>-0 [006] ..s1. 564.696872: my_direct_func: waking up rcu_preempt-17
+ <idle>-0 [007] ..s1. 565.191982: my_direct_func: waking up kcompactd0-63
+
+Setup a function filter to the 'wake_up_process' too, and enable it.
+
+ # cd /sys/kernel/tracing/
+ # echo wake_up_process > set_ftrace_filter
+ # echo function > current_tracer
+ # less trace
+...
+ <idle>-0 [006] ..s3. 686.180972: wake_up_process <-call_timer_fn
+ <idle>-0 [006] ..s3. 686.186919: wake_up_process <-call_timer_fn
+ <idle>-0 [002] ..s3. 686.264049: wake_up_process <-call_timer_fn
+ <idle>-0 [002] d.h6. 686.515216: wake_up_process <-kick_pool
+ <idle>-0 [002] d.h6. 686.691386: wake_up_process <-kick_pool
+
+Then, only function tracer is shown on x86.
+But if you enable 'kprobe on ftrace' event (which uses SAVE_REGS flag)
+on the same function, it is shown again.
+
+ # echo 'p wake_up_process' >> dynamic_events
+ # echo 1 > events/kprobes/p_wake_up_process_0/enable
+ # echo > trace
+ # less trace
+...
+ <idle>-0 [006] ..s2. 2710.345919: p_wake_up_process_0: (wake_up_process+0x4/0x20)
+ <idle>-0 [006] ..s3. 2710.345923: wake_up_process <-call_timer_fn
+ <idle>-0 [006] ..s1. 2710.345928: my_direct_func: waking up rcu_preempt-17
+ <idle>-0 [006] ..s2. 2710.349931: p_wake_up_process_0: (wake_up_process+0x4/0x20)
+ <idle>-0 [006] ..s3. 2710.349934: wake_up_process <-call_timer_fn
+ <idle>-0 [006] ..s1. 2710.349937: my_direct_func: waking up rcu_preempt-17
+
+To fix this issue, use SAVE_REGS flag for multiple ftrace_ops flag of
+direct_call by default.
+
+Link: https://lore.kernel.org/linux-trace-kernel/170484558617.178953.1590516949390270842.stgit@devnote2
+
+Fixes: 60c8971899f3 ("ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS")
+Cc: stable@vger.kernel.org
+Cc: Florent Revest <revest@chromium.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Reviewed-by: Mark Rutland <mark.rutland@arm.com>
+Tested-by: Mark Rutland <mark.rutland@arm.com> [arm64]
+Acked-by: Jiri Olsa <jolsa@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -5325,7 +5325,17 @@ static LIST_HEAD(ftrace_direct_funcs);
+
+ static int register_ftrace_function_nolock(struct ftrace_ops *ops);
+
++/*
++ * If there are multiple ftrace_ops, use SAVE_REGS by default, so that direct
++ * call will be jumped from ftrace_regs_caller. Only if the architecture does
++ * not support ftrace_regs_caller but direct_call, use SAVE_ARGS so that it
++ * jumps from ftrace_caller for multiple ftrace_ops.
++ */
++#ifndef HAVE_DYNAMIC_FTRACE_WITH_REGS
+ #define MULTI_FLAGS (FTRACE_OPS_FL_DIRECT | FTRACE_OPS_FL_SAVE_ARGS)
++#else
++#define MULTI_FLAGS (FTRACE_OPS_FL_DIRECT | FTRACE_OPS_FL_SAVE_REGS)
++#endif
+
+ static int check_direct_multi(struct ftrace_ops *ops)
+ {
--- /dev/null
+From e0526ec5360a48ad3ab2e26e802b0532302a7e11 Mon Sep 17 00:00:00 2001
+From: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+Date: Tue, 30 Jan 2024 23:35:51 -0800
+Subject: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
+
+From: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+
+commit e0526ec5360a48ad3ab2e26e802b0532302a7e11 upstream.
+
+In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
+VMBus channel"), napi_disable was getting called for all channels,
+including all subchannels without confirming if they are enabled or not.
+
+This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
+has finished running but nvdev->subchan_work has not started yet.
+netvsc_subchan_work() -> rndis_set_subchannel() has not created the
+sub-channels and because of that netvsc_sc_open() is not running.
+netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
+netvsc_subchan_work did not run.
+
+netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
+cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
+NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
+opposite.
+
+Now during netvsc_device_remove(), when napi_disable is called for those
+subchannels, napi_disable gets stuck on infinite msleep.
+
+This fix addresses this problem by ensuring that napi_disable() is not
+getting called for non-enabled NAPI struct.
+But netif_napi_del() is still necessary for these non-enabled NAPI struct
+for cleanup purpose.
+
+Call trace:
+[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
+[ 654.568030] Call Trace:
+[ 654.571221] <TASK>
+[ 654.573790] __schedule+0x2d6/0x960
+[ 654.577733] schedule+0x69/0xf0
+[ 654.581214] schedule_timeout+0x87/0x140
+[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
+[ 654.590291] msleep+0x2d/0x40
+[ 654.593625] napi_disable+0x2b/0x80
+[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
+[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
+[ 654.611101] ? do_wait_intr+0xb0/0xb0
+[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
+[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]
+
+Cc: stable@vger.kernel.org
+Fixes: ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel")
+Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/1706686551-28510-1-git-send-email-schakrabarti@linux.microsoft.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/hyperv/netvsc.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/hyperv/netvsc.c
++++ b/drivers/net/hyperv/netvsc.c
+@@ -708,7 +708,10 @@ void netvsc_device_remove(struct hv_devi
+ /* Disable NAPI and disassociate its context from the device. */
+ for (i = 0; i < net_device->num_chn; i++) {
+ /* See also vmbus_reset_channel_cb(). */
+- napi_disable(&net_device->chan_table[i].napi);
++ /* only disable enabled NAPI channel */
++ if (i < ndev->real_num_rx_queues)
++ napi_disable(&net_device->chan_table[i].napi);
++
+ netif_napi_del(&net_device->chan_table[i].napi);
+ }
+
--- /dev/null
+From a37ee9e117ef73bbc2f5c0b31911afd52d229861 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 14 Feb 2024 08:23:05 -0700
+Subject: io_uring/net: fix multishot accept overflow handling
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit a37ee9e117ef73bbc2f5c0b31911afd52d229861 upstream.
+
+If we hit CQ ring overflow when attempting to post a multishot accept
+completion, we don't properly save the result or return code. This
+results in losing the accepted fd value.
+
+Instead, we return the result from the poll operation that triggered
+the accept retry. This is generally POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND
+which is 0xc3, or 195, which looks like a valid file descriptor, but it
+really has no connection to that.
+
+Handle this like we do for other multishot completions - assign the
+result, and return IOU_STOP_MULTISHOT to cancel any further completions
+from this request when overflow is hit. This preserves the result, as we
+should, and tells the application that the request needs to be re-armed.
+
+Cc: stable@vger.kernel.org
+Fixes: 515e26961295 ("io_uring: revert "io_uring fix multishot accept ordering"")
+Link: https://github.com/axboe/liburing/issues/1062
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/net.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/io_uring/net.c
++++ b/io_uring/net.c
+@@ -1372,7 +1372,7 @@ retry:
+ * has already been done
+ */
+ if (issue_flags & IO_URING_F_MULTISHOT)
+- ret = IOU_ISSUE_SKIP_COMPLETE;
++ return IOU_ISSUE_SKIP_COMPLETE;
+ return ret;
+ }
+ if (ret == -ERESTARTSYS)
+@@ -1397,7 +1397,8 @@ retry:
+ ret, IORING_CQE_F_MORE))
+ goto retry;
+
+- return -ECANCELED;
++ io_req_set_res(req, ret, 0);
++ return IOU_STOP_MULTISHOT;
+ }
+
+ int io_socket_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--- /dev/null
+From 108a020c64434fed4b69762879d78cd24088b4c7 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Mon, 5 Feb 2024 14:19:16 +0300
+Subject: ksmbd: free aux buffer if ksmbd_iov_pin_rsp_read fails
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit 108a020c64434fed4b69762879d78cd24088b4c7 upstream.
+
+ksmbd_iov_pin_rsp_read() doesn't free the provided aux buffer if it
+fails. Seems to be the caller's responsibility to clear the buffer in
+error case.
+
+Found by Linux Verification Center (linuxtesting.org).
+
+Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/server/smb2pdu.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -6173,8 +6173,10 @@ static noinline int smb2_read_pipe(struc
+ err = ksmbd_iov_pin_rsp_read(work, (void *)rsp,
+ offsetof(struct smb2_read_rsp, Buffer),
+ aux_payload_buf, nbytes);
+- if (err)
++ if (err) {
++ kvfree(aux_payload_buf);
+ goto out;
++ }
+ kvfree(rpc_resp);
+ } else {
+ err = ksmbd_iov_pin_rsp(work, (void *)rsp,
+@@ -6384,8 +6386,10 @@ int smb2_read(struct ksmbd_work *work)
+ err = ksmbd_iov_pin_rsp_read(work, (void *)rsp,
+ offsetof(struct smb2_read_rsp, Buffer),
+ aux_payload_buf, nbytes);
+- if (err)
++ if (err) {
++ kvfree(aux_payload_buf);
+ goto out;
++ }
+ ksmbd_fd_put(work, fp);
+ return 0;
+
--- /dev/null
+From 6231c9e1a9f35b535c66709aa8a6eda40dbc4132 Mon Sep 17 00:00:00 2001
+From: Prasad Pandit <pjp@fedoraproject.org>
+Date: Wed, 3 Jan 2024 13:23:43 +0530
+Subject: KVM: x86: make KVM_REQ_NMI request iff NMI pending for vcpu
+
+From: Prasad Pandit <pjp@fedoraproject.org>
+
+commit 6231c9e1a9f35b535c66709aa8a6eda40dbc4132 upstream.
+
+kvm_vcpu_ioctl_x86_set_vcpu_events() routine makes 'KVM_REQ_NMI'
+request for a vcpu even when its 'events->nmi.pending' is zero.
+Ex:
+ qemu_thread_start
+ kvm_vcpu_thread_fn
+ qemu_wait_io_event
+ qemu_wait_io_event_common
+ process_queued_cpu_work
+ do_kvm_cpu_synchronize_post_init/_reset
+ kvm_arch_put_registers
+ kvm_put_vcpu_events (cpu, level=[2|3])
+
+This leads vCPU threads in QEMU to constantly acquire & release the
+global mutex lock, delaying the guest boot due to lock contention.
+Add check to make KVM_REQ_NMI request only if vcpu has NMI pending.
+
+Fixes: bdedff263132 ("KVM: x86: Route pending NMIs from userspace through process_nmi()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Prasad Pandit <pjp@fedoraproject.org>
+Link: https://lore.kernel.org/r/20240103075343.549293-1-ppandit@redhat.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -5300,7 +5300,8 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_e
+ if (events->flags & KVM_VCPUEVENT_VALID_NMI_PENDING) {
+ vcpu->arch.nmi_pending = 0;
+ atomic_set(&vcpu->arch.nmi_queued, events->nmi.pending);
+- kvm_make_request(KVM_REQ_NMI, vcpu);
++ if (events->nmi.pending)
++ kvm_make_request(KVM_REQ_NMI, vcpu);
+ }
+ static_call(kvm_x86_set_nmi_mask)(vcpu, events->nmi.masked);
+
--- /dev/null
+From 05519c86d6997cfb9bb6c82ce1595d1015b718dc Mon Sep 17 00:00:00 2001
+From: Mingwei Zhang <mizhang@google.com>
+Date: Tue, 23 Jan 2024 22:12:20 +0000
+Subject: KVM: x86/pmu: Fix type length error when reading pmu->fixed_ctr_ctrl
+
+From: Mingwei Zhang <mizhang@google.com>
+
+commit 05519c86d6997cfb9bb6c82ce1595d1015b718dc upstream.
+
+Use a u64 instead of a u8 when taking a snapshot of pmu->fixed_ctr_ctrl
+when reprogramming fixed counters, as truncating the value results in KVM
+thinking fixed counter 2 is already disabled (the bug also affects fixed
+counters 3+, but KVM doesn't yet support those). As a result, if the
+guest disables fixed counter 2, KVM will get a false negative and fail to
+reprogram/disable emulation of the counter, which can leads to incorrect
+counts and spurious PMIs in the guest.
+
+Fixes: 76d287b2342e ("KVM: x86/pmu: Drop "u8 ctrl, int idx" for reprogram_fixed_counter()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mingwei Zhang <mizhang@google.com>
+Link: https://lore.kernel.org/r/20240123221220.3911317-1-mizhang@google.com
+[sean: rewrite changelog to call out the effects of the bug]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/pmu_intel.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/pmu_intel.c
++++ b/arch/x86/kvm/vmx/pmu_intel.c
+@@ -71,7 +71,7 @@ static int fixed_pmc_events[] = {
+ static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data)
+ {
+ struct kvm_pmc *pmc;
+- u8 old_fixed_ctr_ctrl = pmu->fixed_ctr_ctrl;
++ u64 old_fixed_ctr_ctrl = pmu->fixed_ctr_ctrl;
+ int i;
+
+ pmu->fixed_ctr_ctrl = data;
--- /dev/null
+From cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 Mon Sep 17 00:00:00 2001
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+Date: Tue, 6 Feb 2024 09:39:12 +0100
+Subject: mmc: slot-gpio: Allow non-sleeping GPIO ro
+
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+
+commit cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 upstream.
+
+This change uses the appropriate _cansleep or non-sleeping API for
+reading GPIO read-only state. This allows users with GPIOs that
+never sleepbeing called in atomic context.
+
+Implement the same mechanism as in commit 52af318c93e97 ("mmc: Allow
+non-sleeping GPIO cd").
+
+Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240206083912.2543142-1-alexander.stein@ew.tq-group.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/slot-gpio.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/slot-gpio.c
++++ b/drivers/mmc/core/slot-gpio.c
+@@ -75,11 +75,15 @@ EXPORT_SYMBOL(mmc_gpio_set_cd_irq);
+ int mmc_gpio_get_ro(struct mmc_host *host)
+ {
+ struct mmc_gpio *ctx = host->slot.handler_priv;
++ int cansleep;
+
+ if (!ctx || !ctx->ro_gpio)
+ return -ENOSYS;
+
+- return gpiod_get_value_cansleep(ctx->ro_gpio);
++ cansleep = gpiod_cansleep(ctx->ro_gpio);
++ return cansleep ?
++ gpiod_get_value_cansleep(ctx->ro_gpio) :
++ gpiod_get_value(ctx->ro_gpio);
+ }
+ EXPORT_SYMBOL(mmc_gpio_get_ro);
+
--- /dev/null
+From 585b40e25dc9ff3d2b03d1495150540849009e5b Mon Sep 17 00:00:00 2001
+From: Andrew Lunn <andrew@lunn.ch>
+Date: Mon, 29 Jan 2024 23:49:48 +0100
+Subject: net: dsa: mv88e6xxx: Fix failed probe due to unsupported C45 reads
+
+From: Andrew Lunn <andrew@lunn.ch>
+
+commit 585b40e25dc9ff3d2b03d1495150540849009e5b upstream.
+
+Not all mv88e6xxx device support C45 read/write operations. Those
+which do not return -EOPNOTSUPP. However, when phylib scans the bus,
+it considers this fatal, and the probe of the MDIO bus fails, which in
+term causes the mv88e6xxx probe as a whole to fail.
+
+When there is no device on the bus for a given address, the pull up
+resistor on the data line results in the read returning 0xffff. The
+phylib core code understands this when scanning for devices on the
+bus. C45 allows multiple devices to be supported at one address, so
+phylib will perform a few reads at each address, so although thought
+not the most efficient solution, it is a way to avoid fatal
+errors. Make use of this as a minimal fix for stable to fix the
+probing problems.
+
+Follow up patches will rework how C45 operates to make it similar to
+C22 which considers -ENODEV as a none-fatal, and swap mv88e6xxx to
+using this.
+
+Cc: stable@vger.kernel.org
+Fixes: 743a19e38d02 ("net: dsa: mv88e6xxx: Separate C22 and C45 transactions")
+Reported-by: Tim Menninger <tmenninger@purestorage.com>
+Signed-off-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://lore.kernel.org/r/20240129224948.1531452-1-andrew@lunn.ch
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/dsa/mv88e6xxx/chip.c
++++ b/drivers/net/dsa/mv88e6xxx/chip.c
+@@ -3545,7 +3545,7 @@ static int mv88e6xxx_mdio_read_c45(struc
+ int err;
+
+ if (!chip->info->ops->phy_read_c45)
+- return -EOPNOTSUPP;
++ return 0xffff;
+
+ mv88e6xxx_reg_lock(chip);
+ err = chip->info->ops->phy_read_c45(chip, bus, phy, devad, reg, &val);
--- /dev/null
+From cefa98e806fd4e2a5e2047457a11ae5f17b8f621 Mon Sep 17 00:00:00 2001
+From: Hui Zhou <hui.zhou@corigine.com>
+Date: Wed, 24 Jan 2024 17:19:08 +0200
+Subject: nfp: flower: add hardware offload check for post ct entry
+
+From: Hui Zhou <hui.zhou@corigine.com>
+
+commit cefa98e806fd4e2a5e2047457a11ae5f17b8f621 upstream.
+
+The nfp offload flow pay will not allocate a mask id when the out port
+is openvswitch internal port. This is because these flows are used to
+configure the pre_tun table and are never actually send to the firmware
+as an add-flow message. When a tc rule which action contains ct and
+the post ct entry's out port is openvswitch internal port, the merge
+offload flow pay with the wrong mask id of 0 will be send to the
+firmware. Actually, the nfp can not support hardware offload for this
+situation, so return EOPNOTSUPP.
+
+Fixes: bd0fe7f96a3c ("nfp: flower-ct: add zone table entry when handling pre/post_ct flows")
+CC: stable@vger.kernel.org # 5.14+
+Signed-off-by: Hui Zhou <hui.zhou@corigine.com>
+Signed-off-by: Louis Peens <louis.peens@corigine.com>
+Link: https://lore.kernel.org/r/20240124151909.31603-2-louis.peens@corigine.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/netronome/nfp/flower/conntrack.c | 22 +++++++++++++++++-
+ 1 file changed, 21 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
+@@ -1864,10 +1864,30 @@ int nfp_fl_ct_handle_post_ct(struct nfp_
+ {
+ struct flow_rule *rule = flow_cls_offload_flow_rule(flow);
+ struct nfp_fl_ct_flow_entry *ct_entry;
++ struct flow_action_entry *ct_goto;
+ struct nfp_fl_ct_zone_entry *zt;
++ struct flow_action_entry *act;
+ bool wildcarded = false;
+ struct flow_match_ct ct;
+- struct flow_action_entry *ct_goto;
++ int i;
++
++ flow_action_for_each(i, act, &rule->action) {
++ switch (act->id) {
++ case FLOW_ACTION_REDIRECT:
++ case FLOW_ACTION_REDIRECT_INGRESS:
++ case FLOW_ACTION_MIRRED:
++ case FLOW_ACTION_MIRRED_INGRESS:
++ if (act->dev->rtnl_link_ops &&
++ !strcmp(act->dev->rtnl_link_ops->kind, "openvswitch")) {
++ NL_SET_ERR_MSG_MOD(extack,
++ "unsupported offload: out port is openvswitch internal port");
++ return -EOPNOTSUPP;
++ }
++ break;
++ default:
++ break;
++ }
++ }
+
+ flow_rule_match_ct(rule, &ct);
+ if (!ct.mask->ct_zone) {
--- /dev/null
+From 3a007b8009b5f8af021021b7a590a6da0dc4c6e0 Mon Sep 17 00:00:00 2001
+From: Hui Zhou <hui.zhou@corigine.com>
+Date: Wed, 24 Jan 2024 17:19:09 +0200
+Subject: nfp: flower: fix hardware offload for the transfer layer port
+
+From: Hui Zhou <hui.zhou@corigine.com>
+
+commit 3a007b8009b5f8af021021b7a590a6da0dc4c6e0 upstream.
+
+The nfp driver will merge the tp source port and tp destination port
+into one dword which the offset must be zero to do hardware offload.
+However, the mangle action for the tp source port and tp destination
+port is separated for tc ct action. Modify the mangle action for the
+FLOW_ACT_MANGLE_HDR_TYPE_TCP and FLOW_ACT_MANGLE_HDR_TYPE_UDP to
+satisfy the nfp driver offload check for the tp port.
+
+The mangle action provides a 4B value for source, and a 4B value for
+the destination, but only 2B of each contains the useful information.
+For offload the 2B of each is combined into a single 4B word. Since the
+incoming mask for the source is '0xFFFF<mask>' the shift-left will
+throw away the 0xFFFF part. When this gets combined together in the
+offload it will clear the destination field. Fix this by setting the
+lower bits back to 0xFFFF, effectively doing a rotate-left operation on
+the mask.
+
+Fixes: 5cee92c6f57a ("nfp: flower: support hw offload for ct nat action")
+CC: stable@vger.kernel.org # 6.1+
+Signed-off-by: Hui Zhou <hui.zhou@corigine.com>
+Signed-off-by: Louis Peens <louis.peens@corigine.com>
+Link: https://lore.kernel.org/r/20240124151909.31603-3-louis.peens@corigine.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/netronome/nfp/flower/conntrack.c | 24 ++++++++++++++++--
+ 1 file changed, 22 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
+@@ -1424,10 +1424,30 @@ static void nfp_nft_ct_translate_mangle_
+ mangle_action->mangle.mask = (__force u32)cpu_to_be32(mangle_action->mangle.mask);
+ return;
+
++ /* Both struct tcphdr and struct udphdr start with
++ * __be16 source;
++ * __be16 dest;
++ * so we can use the same code for both.
++ */
+ case FLOW_ACT_MANGLE_HDR_TYPE_TCP:
+ case FLOW_ACT_MANGLE_HDR_TYPE_UDP:
+- mangle_action->mangle.val = (__force u16)cpu_to_be16(mangle_action->mangle.val);
+- mangle_action->mangle.mask = (__force u16)cpu_to_be16(mangle_action->mangle.mask);
++ if (mangle_action->mangle.offset == offsetof(struct tcphdr, source)) {
++ mangle_action->mangle.val =
++ (__force u32)cpu_to_be32(mangle_action->mangle.val << 16);
++ /* The mask of mangle action is inverse mask,
++ * so clear the dest tp port with 0xFFFF to
++ * instead of rotate-left operation.
++ */
++ mangle_action->mangle.mask =
++ (__force u32)cpu_to_be32(mangle_action->mangle.mask << 16 | 0xFFFF);
++ }
++ if (mangle_action->mangle.offset == offsetof(struct tcphdr, dest)) {
++ mangle_action->mangle.offset = 0;
++ mangle_action->mangle.val =
++ (__force u32)cpu_to_be32(mangle_action->mangle.val);
++ mangle_action->mangle.mask =
++ (__force u32)cpu_to_be32(mangle_action->mangle.mask);
++ }
+ return;
+
+ default:
--- /dev/null
+From 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Date: Wed, 24 Jan 2024 21:19:36 +0900
+Subject: nilfs2: fix data corruption in dsync block recovery for small block sizes
+
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+
+commit 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 upstream.
+
+The helper function nilfs_recovery_copy_block() of
+nilfs_recovery_dsync_blocks(), which recovers data from logs created by
+data sync writes during a mount after an unclean shutdown, incorrectly
+calculates the on-page offset when copying repair data to the file's page
+cache. In environments where the block size is smaller than the page
+size, this flaw can cause data corruption and leak uninitialized memory
+bytes during the recovery process.
+
+Fix these issues by correcting this byte offset calculation on the page.
+
+Link: https://lkml.kernel.org/r/20240124121936.10575-1-konishi.ryusuke@gmail.com
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/recovery.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/fs/nilfs2/recovery.c
++++ b/fs/nilfs2/recovery.c
+@@ -472,9 +472,10 @@ static int nilfs_prepare_segment_for_rec
+
+ static int nilfs_recovery_copy_block(struct the_nilfs *nilfs,
+ struct nilfs_recovery_block *rb,
+- struct page *page)
++ loff_t pos, struct page *page)
+ {
+ struct buffer_head *bh_org;
++ size_t from = pos & ~PAGE_MASK;
+ void *kaddr;
+
+ bh_org = __bread(nilfs->ns_bdev, rb->blocknr, nilfs->ns_blocksize);
+@@ -482,7 +483,7 @@ static int nilfs_recovery_copy_block(str
+ return -EIO;
+
+ kaddr = kmap_atomic(page);
+- memcpy(kaddr + bh_offset(bh_org), bh_org->b_data, bh_org->b_size);
++ memcpy(kaddr + from, bh_org->b_data, bh_org->b_size);
+ kunmap_atomic(kaddr);
+ brelse(bh_org);
+ return 0;
+@@ -521,7 +522,7 @@ static int nilfs_recover_dsync_blocks(st
+ goto failed_inode;
+ }
+
+- err = nilfs_recovery_copy_block(nilfs, rb, page);
++ err = nilfs_recovery_copy_block(nilfs, rb, pos, page);
+ if (unlikely(err))
+ goto failed_page;
+
--- /dev/null
+From 38296afe3c6ee07319e01bb249aa4bb47c07b534 Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Date: Wed, 31 Jan 2024 23:56:57 +0900
+Subject: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
+
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+
+commit 38296afe3c6ee07319e01bb249aa4bb47c07b534 upstream.
+
+Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
+and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
+
+While migrate_pages_batch() locks a folio and waits for the writeback to
+complete, the log writer thread that should bring the writeback to
+completion picks up the folio being written back in
+nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
+creation and was trying to lock the folio. Thus causing a deadlock.
+
+In the first place, it is unexpected that folios/pages in the middle of
+writeback will be updated and become dirty. Nilfs2 adds a checksum to
+verify the validity of the log being written and uses it for recovery at
+mount, so data changes during writeback are suppressed. Since this is
+broken, an unclean shutdown could potentially cause recovery to fail.
+
+Investigation revealed that the root cause is that the wait for writeback
+completion in nilfs_page_mkwrite() is conditional, and if the backing
+device does not require stable writes, data may be modified without
+waiting.
+
+Fix these issues by making nilfs_page_mkwrite() wait for writeback to
+finish regardless of the stable write requirement of the backing device.
+
+Link: https://lkml.kernel.org/r/20240131145657.4209-1-konishi.ryusuke@gmail.com
+Fixes: 1d1d1a767206 ("mm: only enforce stable page writes if the backing device requires it")
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Reported-by: syzbot+ee2ae68da3b22d04cd8d@syzkaller.appspotmail.com
+Closes: https://lkml.kernel.org/r/00000000000047d819061004ad6c@google.com
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nilfs2/file.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/nilfs2/file.c
++++ b/fs/nilfs2/file.c
+@@ -105,7 +105,13 @@ static vm_fault_t nilfs_page_mkwrite(str
+ nilfs_transaction_commit(inode->i_sb);
+
+ mapped:
+- wait_for_stable_page(page);
++ /*
++ * Since checksumming including data blocks is performed to determine
++ * the validity of the log to be written and used for recovery, it is
++ * necessary to wait for writeback to finish here, regardless of the
++ * stable write requirement of the backing device.
++ */
++ wait_on_page_writeback(page);
+ out:
+ sb_end_pagefault(inode->i_sb);
+ return vmf_fs_error(ret);
--- /dev/null
+From aad98efd0b121f63a2e1c221dcb4d4850128c697 Mon Sep 17 00:00:00 2001
+From: Naveen N Rao <naveen@kernel.org>
+Date: Fri, 2 Feb 2024 21:13:16 +0530
+Subject: powerpc/64: Set task pt_regs->link to the LR value on scv entry
+
+From: Naveen N Rao <naveen@kernel.org>
+
+commit aad98efd0b121f63a2e1c221dcb4d4850128c697 upstream.
+
+Nysal reported that userspace backtraces are missing in offcputime bcc
+tool. As an example:
+ $ sudo ./bcc/tools/offcputime.py -uU
+ Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
+
+ ^C
+ write
+ - python (9107)
+ 8
+
+ write
+ - sudo (9105)
+ 9
+
+ mmap
+ - python (9107)
+ 16
+
+ clock_nanosleep
+ - multipathd (697)
+ 3001604
+
+The offcputime bcc tool attaches a bpf program to a kprobe on
+finish_task_switch(), which is usually hit on a syscall from userspace.
+With the switch to system call vectored, we started setting
+pt_regs->link to zero. This is because system call vectored behaves like
+a function call with LR pointing to the system call return address, and
+with no modification to SRR0/SRR1. The LR value does indicate our next
+instruction, so it is being saved as pt_regs->nip, and pt_regs->link is
+being set to zero. This is not a problem by itself, but BPF uses perf
+callchain infrastructure for capturing stack traces, and that stores LR
+as the second entry in the stack trace. perf has code to cope with the
+second entry being zero, and skips over it. However, generic userspace
+unwinders assume that a zero entry indicates end of the stack trace,
+resulting in a truncated userspace stack trace.
+
+Rather than fixing all userspace unwinders to ignore/skip past the
+second entry, store the real LR value in pt_regs->link so that there
+continues to be a valid, though duplicate entry in the stack trace.
+
+With this change:
+ $ sudo ./bcc/tools/offcputime.py -uU
+ Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
+
+ ^C
+ write
+ write
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ PyObject_VectorcallMethod
+ [unknown]
+ [unknown]
+ PyObject_CallOneArg
+ PyFile_WriteObject
+ PyFile_WriteString
+ [unknown]
+ [unknown]
+ PyObject_Vectorcall
+ _PyEval_EvalFrameDefault
+ PyEval_EvalCode
+ [unknown]
+ [unknown]
+ [unknown]
+ _PyRun_SimpleFileObject
+ _PyRun_AnyFileObject
+ Py_RunMain
+ [unknown]
+ Py_BytesMain
+ [unknown]
+ __libc_start_main
+ - python (1293)
+ 7
+
+ write
+ write
+ [unknown]
+ sudo_ev_loop_v1
+ sudo_ev_dispatch_v1
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ __libc_start_main
+ - sudo (1291)
+ 7
+
+ syscall
+ syscall
+ bpf_open_perf_buffer_opts
+ [unknown]
+ [unknown]
+ [unknown]
+ [unknown]
+ _PyObject_MakeTpCall
+ PyObject_Vectorcall
+ _PyEval_EvalFrameDefault
+ PyEval_EvalCode
+ [unknown]
+ [unknown]
+ [unknown]
+ _PyRun_SimpleFileObject
+ _PyRun_AnyFileObject
+ Py_RunMain
+ [unknown]
+ Py_BytesMain
+ [unknown]
+ __libc_start_main
+ - python (1293)
+ 11
+
+ clock_nanosleep
+ clock_nanosleep
+ nanosleep
+ sleep
+ [unknown]
+ [unknown]
+ __clone
+ - multipathd (698)
+ 3001661
+
+Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
+Cc: stable@vger.kernel.org
+Reported-by: "Nysal Jan K.A" <nysal@linux.ibm.com>
+Signed-off-by: Naveen N Rao <naveen@kernel.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/interrupt_64.S | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/kernel/interrupt_64.S
++++ b/arch/powerpc/kernel/interrupt_64.S
+@@ -52,7 +52,8 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectore
+ mr r10,r1
+ ld r1,PACAKSAVE(r13)
+ std r10,0(r1)
+- std r11,_NIP(r1)
++ std r11,_LINK(r1)
++ std r11,_NIP(r1) /* Saved LR is also the next instruction */
+ std r12,_MSR(r1)
+ std r0,GPR0(r1)
+ std r10,GPR1(r1)
+@@ -70,7 +71,6 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectore
+ std r9,GPR13(r1)
+ SAVE_NVGPRS(r1)
+ std r11,_XER(r1)
+- std r11,_LINK(r1)
+ std r11,_CTR(r1)
+
+ li r11,\trapnr
--- /dev/null
+From eb6d871f4ba49ac8d0537e051fe983a3a4027f61 Mon Sep 17 00:00:00 2001
+From: David Engraf <david.engraf@sysgo.com>
+Date: Wed, 7 Feb 2024 10:27:58 +0100
+Subject: powerpc/cputable: Add missing PPC_FEATURE_BOOKE on PPC64 Book-E
+
+From: David Engraf <david.engraf@sysgo.com>
+
+commit eb6d871f4ba49ac8d0537e051fe983a3a4027f61 upstream.
+
+Commit e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of
+cputable.h") moved the cpu_specs to separate header files. Previously
+PPC_FEATURE_BOOKE was enabled by CONFIG_PPC_BOOK3E_64. The definition in
+cpu_specs_e500mc.h for PPC64 no longer enables PPC_FEATURE_BOOKE.
+
+This breaks user space reading the ELF hwcaps and expect
+PPC_FEATURE_BOOKE. Debugging an application with gdb is no longer
+working on e5500/e6500 because the 64-bit detection relies on
+PPC_FEATURE_BOOKE for Book-E.
+
+Fixes: e320a76db4b0 ("powerpc/cputable: Split cpu_specs[] out of cputable.h")
+Cc: stable@vger.kernel.org # v6.1+
+Signed-off-by: David Engraf <david.engraf@sysgo.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240207092758.1058893-1-david.engraf@sysgo.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/cpu_specs_e500mc.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/cpu_specs_e500mc.h
++++ b/arch/powerpc/kernel/cpu_specs_e500mc.h
+@@ -8,7 +8,8 @@
+
+ #ifdef CONFIG_PPC64
+ #define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
+- PPC_FEATURE_HAS_FPU | PPC_FEATURE_64)
++ PPC_FEATURE_HAS_FPU | PPC_FEATURE_64 | \
++ PPC_FEATURE_BOOKE)
+ #else
+ #define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
+ PPC_FEATURE_BOOKE)
--- /dev/null
+From cbecc9fcbbec60136b0180ba0609c829afed5c81 Mon Sep 17 00:00:00 2001
+From: Shrikanth Hegde <sshegde@linux.ibm.com>
+Date: Tue, 13 Feb 2024 10:56:35 +0530
+Subject: powerpc/pseries: fix accuracy of stolen time
+
+From: Shrikanth Hegde <sshegde@linux.ibm.com>
+
+commit cbecc9fcbbec60136b0180ba0609c829afed5c81 upstream.
+
+powerVM hypervisor updates the VPA fields with stolen time data.
+It currently reports enqueue_dispatch_tb and ready_enqueue_tb for
+this purpose. In linux these two fields are used to report the stolen time.
+
+The VPA fields are updated at the TB frequency. On powerPC its mostly
+set at 512Mhz. Hence this needs a conversion to ns when reporting it
+back as rest of the kernel timings are in ns. This conversion is already
+handled in tb_to_ns function. So use that function to report accurate
+stolen time.
+
+Observed this issue and used an Capped Shared Processor LPAR(SPLPAR) to
+simplify the experiments. In all these cases, 100% VP Load is run using
+stress-ng workload. Values of stolen time is in percentages as reported
+by mpstat. With the patch values are close to expected.
+
+ 6.8.rc1 +Patch
+12EC/12VP 0.0 0.0
+12EC/24VP 25.7 50.2
+12EC/36VP 37.3 69.2
+12EC/48VP 38.5 78.3
+
+Fixes: 0e8a63132800 ("powerpc/pseries: Implement CONFIG_PARAVIRT_TIME_ACCOUNTING")
+Cc: stable@vger.kernel.org # v6.1+
+Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
+Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
+Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240213052635.231597-1-sshegde@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/pseries/lpar.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/lpar.c
++++ b/arch/powerpc/platforms/pseries/lpar.c
+@@ -662,8 +662,12 @@ u64 pseries_paravirt_steal_clock(int cpu
+ {
+ struct lppaca *lppaca = &lppaca_of(cpu);
+
+- return be64_to_cpu(READ_ONCE(lppaca->enqueue_dispatch_tb)) +
+- be64_to_cpu(READ_ONCE(lppaca->ready_enqueue_tb));
++ /*
++ * VPA steal time counters are reported at TB frequency. Hence do a
++ * conversion to ns before returning
++ */
++ return tb_to_ns(be64_to_cpu(READ_ONCE(lppaca->enqueue_dispatch_tb)) +
++ be64_to_cpu(READ_ONCE(lppaca->ready_enqueue_tb)));
+ }
+ #endif
+
--- /dev/null
+From 66bbea9ed6446b8471d365a22734dc00556c4785 Mon Sep 17 00:00:00 2001
+From: Vincent Donnefort <vdonnefort@google.com>
+Date: Wed, 31 Jan 2024 14:09:55 +0000
+Subject: ring-buffer: Clean ring_buffer_poll_wait() error return
+
+From: Vincent Donnefort <vdonnefort@google.com>
+
+commit 66bbea9ed6446b8471d365a22734dc00556c4785 upstream.
+
+The return type for ring_buffer_poll_wait() is __poll_t. This is behind
+the scenes an unsigned where we can set event bits. In case of a
+non-allocated CPU, we do return instead -EINVAL (0xffffffea). Lucky us,
+this ends up setting few error bits (EPOLLERR | EPOLLHUP | EPOLLNVAL), so
+user-space at least is aware something went wrong.
+
+Nonetheless, this is an incorrect code. Replace that -EINVAL with a
+proper EPOLLERR to clean that output. As this doesn't change the
+behaviour, there's no need to treat this change as a bug fix.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20240131140955.3322792-1-vdonnefort@google.com
+
+Cc: stable@vger.kernel.org
+Fixes: 6721cb6002262 ("ring-buffer: Do not poll non allocated cpu buffers")
+Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1091,7 +1091,7 @@ __poll_t ring_buffer_poll_wait(struct tr
+ full = 0;
+ } else {
+ if (!cpumask_test_cpu(cpu, buffer->cpumask))
+- return -EINVAL;
++ return EPOLLERR;
+
+ cpu_buffer = buffer->buffers[cpu];
+ work = &cpu_buffer->irq_work;
--- /dev/null
+From 3ee07964d407411fd578a3bc998de44fd64d266a Mon Sep 17 00:00:00 2001
+From: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
+Date: Thu, 1 Feb 2024 11:55:56 +0100
+Subject: serial: core: introduce uart_port_tx_flags()
+
+From: Jiri Slaby (SUSE) <jirislaby@kernel.org>
+
+commit 3ee07964d407411fd578a3bc998de44fd64d266a upstream.
+
+And an enum with a flag: UART_TX_NOSTOP. To NOT call
+__port->ops->stop_tx() when the circular buffer is empty. mxs-uart needs
+this (see the next patch).
+
+Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
+Cc: stable <stable@kernel.org>
+Tested-by: Emil Kronborg <emil.kronborg@protonmail.com>
+Link: https://lore.kernel.org/r/20240201105557.28043-1-jirislaby@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/serial_core.h | 32 +++++++++++++++++++++++++++-----
+ 1 file changed, 27 insertions(+), 5 deletions(-)
+
+--- a/include/linux/serial_core.h
++++ b/include/linux/serial_core.h
+@@ -748,8 +748,17 @@ struct uart_driver {
+
+ void uart_write_wakeup(struct uart_port *port);
+
+-#define __uart_port_tx(uport, ch, tx_ready, put_char, tx_done, for_test, \
+- for_post) \
++/**
++ * enum UART_TX_FLAGS -- flags for uart_port_tx_flags()
++ *
++ * @UART_TX_NOSTOP: don't call port->ops->stop_tx() on empty buffer
++ */
++enum UART_TX_FLAGS {
++ UART_TX_NOSTOP = BIT(0),
++};
++
++#define __uart_port_tx(uport, ch, flags, tx_ready, put_char, tx_done, \
++ for_test, for_post) \
+ ({ \
+ struct uart_port *__port = (uport); \
+ struct circ_buf *xmit = &__port->state->xmit; \
+@@ -777,7 +786,7 @@ void uart_write_wakeup(struct uart_port
+ if (pending < WAKEUP_CHARS) { \
+ uart_write_wakeup(__port); \
+ \
+- if (pending == 0) \
++ if (!((flags) & UART_TX_NOSTOP) && pending == 0) \
+ __port->ops->stop_tx(__port); \
+ } \
+ \
+@@ -812,7 +821,7 @@ void uart_write_wakeup(struct uart_port
+ */
+ #define uart_port_tx_limited(port, ch, count, tx_ready, put_char, tx_done) ({ \
+ unsigned int __count = (count); \
+- __uart_port_tx(port, ch, tx_ready, put_char, tx_done, __count, \
++ __uart_port_tx(port, ch, 0, tx_ready, put_char, tx_done, __count, \
+ __count--); \
+ })
+
+@@ -826,8 +835,21 @@ void uart_write_wakeup(struct uart_port
+ * See uart_port_tx_limited() for more details.
+ */
+ #define uart_port_tx(port, ch, tx_ready, put_char) \
+- __uart_port_tx(port, ch, tx_ready, put_char, ({}), true, ({}))
++ __uart_port_tx(port, ch, 0, tx_ready, put_char, ({}), true, ({}))
+
++
++/**
++ * uart_port_tx_flags -- transmit helper for uart_port with flags
++ * @port: uart port
++ * @ch: variable to store a character to be written to the HW
++ * @flags: %UART_TX_NOSTOP or similar
++ * @tx_ready: can HW accept more data function
++ * @put_char: function to write a character
++ *
++ * See uart_port_tx_limited() for more details.
++ */
++#define uart_port_tx_flags(port, ch, flags, tx_ready, put_char) \
++ __uart_port_tx(port, ch, flags, tx_ready, put_char, ({}), true, ({}))
+ /*
+ * Baud rate helpers.
+ */
--- /dev/null
+From 8afa6c6decea37e7cb473d2c60473f37f46cea35 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:30:00 -0500
+Subject: serial: max310x: fail probe if clock crystal is unstable
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 8afa6c6decea37e7cb473d2c60473f37f46cea35 upstream.
+
+A stable clock is really required in order to use this UART, so log an
+error message and bail out if the chip reports that the clock is not
+stable.
+
+Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
+Cc: stable@vger.kernel.org
+Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
+Link: https://www.spinics.net/lists/linux-serial/msg35773.html
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-4-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -587,7 +587,7 @@ static int max310x_update_best_err(unsig
+ return 1;
+ }
+
+-static u32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
++static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
+ unsigned long freq, bool xtal)
+ {
+ unsigned int div, clksrc, pllcfg = 0;
+@@ -657,7 +657,8 @@ static u32 max310x_set_ref_clk(struct de
+ } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES));
+
+ if (!stable)
+- dev_warn(dev, "clock is not stable yet\n");
++ return dev_err_probe(dev, -EAGAIN,
++ "clock is not stable\n");
+ }
+
+ return bestfreq;
+@@ -1282,7 +1283,7 @@ static int max310x_probe(struct device *
+ {
+ int i, ret, fmin, fmax, freq;
+ struct max310x_port *s;
+- u32 uartclk = 0;
++ s32 uartclk = 0;
+ bool xtal;
+
+ for (i = 0; i < devtype->nr; i++)
+@@ -1360,6 +1361,11 @@ static int max310x_probe(struct device *
+ }
+
+ uartclk = max310x_set_ref_clk(dev, s, freq, xtal);
++ if (uartclk < 0) {
++ ret = uartclk;
++ goto out_uart;
++ }
++
+ dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk);
+
+ for (i = 0; i < devtype->nr; i++) {
--- /dev/null
+From 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:29:59 -0500
+Subject: serial: max310x: improve crystal stable clock detection
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 upstream.
+
+Some people are seeing a warning similar to this when using a crystal:
+
+ max310x 11-006c: clock is not stable yet
+
+The datasheet doesn't mention the maximum time to wait for the clock to be
+stable when using a crystal, and it seems that the 10ms delay in the driver
+is not always sufficient.
+
+Jan Kundrát reported that it took three tries (each separated by 10ms) to
+get a stable clock.
+
+Modify behavior to check stable clock ready bit multiple times (20), and
+waiting 10ms between each try.
+
+Note: the first draft of the driver originally used a 50ms delay, without
+checking the clock stable bit.
+Then a loop with 1000 retries was implemented, each time reading the clock
+stable bit.
+
+Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
+Cc: stable@vger.kernel.org
+Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
+Link: https://www.spinics.net/lists/linux-serial/msg35773.html
+Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw
+Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -237,6 +237,10 @@
+ #define MAX310x_REV_MASK (0xf8)
+ #define MAX310X_WRITE_BIT 0x80
+
++/* Crystal-related definitions */
++#define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */
++#define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */
++
+ /* MAX3107 specific */
+ #define MAX3107_REV_ID (0xa0)
+
+@@ -641,12 +645,19 @@ static u32 max310x_set_ref_clk(struct de
+
+ /* Wait for crystal */
+ if (xtal) {
+- unsigned int val = 0;
+- msleep(10);
+- regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
+- if (!(val & MAX310X_STS_CLKREADY_BIT)) {
++ bool stable = false;
++ unsigned int try = 0, val = 0;
++
++ do {
++ msleep(MAX310X_XTAL_WAIT_DELAY_MS);
++ regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
++
++ if (val & MAX310X_STS_CLKREADY_BIT)
++ stable = true;
++ } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES));
++
++ if (!stable)
+ dev_warn(dev, "clock is not stable yet\n");
+- }
+ }
+
+ return bestfreq;
--- /dev/null
+From b35f8dbbce818b02c730dc85133dc7754266e084 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:30:01 -0500
+Subject: serial: max310x: prevent infinite while() loop in port startup
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit b35f8dbbce818b02c730dc85133dc7754266e084 upstream.
+
+If there is a problem after resetting a port, the do/while() loop that
+checks the default value of DIVLSB register may run forever and spam the
+I2C bus.
+
+Add a delay before each read of DIVLSB, and a maximum number of tries to
+prevent that situation from happening.
+
+Also fail probe if port reset is unsuccessful.
+
+Fixes: 10d8b34a4217 ("serial: max310x: Driver rework")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-5-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 20 ++++++++++++++++++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -237,6 +237,10 @@
+ #define MAX310x_REV_MASK (0xf8)
+ #define MAX310X_WRITE_BIT 0x80
+
++/* Port startup definitions */
++#define MAX310X_PORT_STARTUP_WAIT_RETRIES 20 /* Number of retries */
++#define MAX310X_PORT_STARTUP_WAIT_DELAY_MS 10 /* Delay between retries */
++
+ /* Crystal-related definitions */
+ #define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */
+ #define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */
+@@ -1346,6 +1350,9 @@ static int max310x_probe(struct device *
+ goto out_clk;
+
+ for (i = 0; i < devtype->nr; i++) {
++ bool started = false;
++ unsigned int try = 0, val = 0;
++
+ /* Reset port */
+ regmap_write(regmaps[i], MAX310X_MODE2_REG,
+ MAX310X_MODE2_RST_BIT);
+@@ -1354,8 +1361,17 @@ static int max310x_probe(struct device *
+
+ /* Wait for port startup */
+ do {
+- regmap_read(regmaps[i], MAX310X_BRGDIVLSB_REG, &ret);
+- } while (ret != 0x01);
++ msleep(MAX310X_PORT_STARTUP_WAIT_DELAY_MS);
++ regmap_read(regmaps[i], MAX310X_BRGDIVLSB_REG, &val);
++
++ if (val == 0x01)
++ started = true;
++ } while (!started && (++try < MAX310X_PORT_STARTUP_WAIT_RETRIES));
++
++ if (!started) {
++ ret = dev_err_probe(dev, -EAGAIN, "port reset failed\n");
++ goto out_uart;
++ }
+
+ regmap_write(regmaps[i], MAX310X_MODE1_REG, devtype->mode1);
+ }
--- /dev/null
+From 0419373333c2f2024966d36261fd82a453281e80 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Tue, 16 Jan 2024 16:29:58 -0500
+Subject: serial: max310x: set default value when reading clock ready bit
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 0419373333c2f2024966d36261fd82a453281e80 upstream.
+
+If regmap_read() returns a non-zero value, the 'val' variable can be left
+uninitialized.
+
+Clear it before calling regmap_read() to make sure we properly detect
+the clock ready bit.
+
+Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20240116213001.3691629-2-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -641,7 +641,7 @@ static u32 max310x_set_ref_clk(struct de
+
+ /* Wait for crystal */
+ if (xtal) {
+- unsigned int val;
++ unsigned int val = 0;
+ msleep(10);
+ regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
+ if (!(val & MAX310X_STS_CLKREADY_BIT)) {
--- /dev/null
+From 7be50f2e8f20fc2299069b28dea59a28e3abe20a Mon Sep 17 00:00:00 2001
+From: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
+Date: Thu, 1 Feb 2024 11:55:57 +0100
+Subject: serial: mxs-auart: fix tx
+
+From: Jiri Slaby (SUSE) <jirislaby@kernel.org>
+
+commit 7be50f2e8f20fc2299069b28dea59a28e3abe20a upstream.
+
+Emil reports:
+ After updating Linux on an i.MX28 board, serial communication over
+ AUART broke. When I TX from the board and measure on the TX pin, it
+ seems like the HW fifo is not emptied before the transmission is
+ stopped.
+
+MXS performs weird things with stop_tx(). The driver makes it
+conditional on uart_tx_stopped().
+
+So the driver needs special handling. Pass the brand new UART_TX_NOSTOP
+to uart_port_tx_flags() and handle the stop on its own.
+
+Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
+Reported-by: Emil Kronborg <emil.kronborg@protonmail.com>
+Cc: stable <stable@kernel.org>
+Fixes: 2d141e683e9a ("tty: serial: use uart_port_tx() helper")
+Closes: https://lore.kernel.org/all/miwgbnvy3hjpnricubg76ytpn7xoceehwahupy25bubbduu23s@om2lptpa26xw/
+Tested-by: Stefan Wahren <wahrenst@gmx.net>
+Tested-by: Emil Kronborg <emil.kronborg@protonmail.com>
+Link: https://lore.kernel.org/r/20240201105557.28043-2-jirislaby@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/mxs-auart.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/mxs-auart.c
++++ b/drivers/tty/serial/mxs-auart.c
+@@ -605,13 +605,16 @@ static void mxs_auart_tx_chars(struct mx
+ return;
+ }
+
+- pending = uart_port_tx(&s->port, ch,
++ pending = uart_port_tx_flags(&s->port, ch, UART_TX_NOSTOP,
+ !(mxs_read(s, REG_STAT) & AUART_STAT_TXFF),
+ mxs_write(ch, s, REG_DATA));
+ if (pending)
+ mxs_set(AUART_INTR_TXIEN, s, REG_INTR);
+ else
+ mxs_clr(AUART_INTR_TXIEN, s, REG_INTR);
++
++ if (uart_tx_stopped(&s->port))
++ mxs_auart_stop_tx(&s->port);
+ }
+
+ static void mxs_auart_rx_char(struct mxs_auart_port *s)
iio-pressure-bmp280-add-missing-bmp085-to-spi-id-table.patch
pmdomain-mediatek-fix-race-conditions-with-genpd.patch
media-rc-bpf-attach-detach-requires-write-permission.patch
+ksmbd-free-aux-buffer-if-ksmbd_iov_pin_rsp_read-fails.patch
+drm-msm-wire-up-tlb-ops.patch
+drm-amd-display-add-align-done-check.patch
+drm-prime-support-page-array-4gb.patch
+drm-amdgpu-soc21-update-vcn-4-max-hevc-encoding-resolution.patch
+drm-amd-display-fix-mst-null-ptr-for-rv.patch
+drm-amd-display-increase-frame-larger-than-for-all-display_mode_vba-files.patch
+drm-amd-display-preserve-original-aspect-ratio-in-create-stream.patch
+hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch
+ring-buffer-clean-ring_buffer_poll_wait-error-return.patch
+net-dsa-mv88e6xxx-fix-failed-probe-due-to-unsupported-c45-reads.patch
+nfp-flower-add-hardware-offload-check-for-post-ct-entry.patch
+nfp-flower-fix-hardware-offload-for-the-transfer-layer-port.patch
+serial-max310x-set-default-value-when-reading-clock-ready-bit.patch
+serial-max310x-improve-crystal-stable-clock-detection.patch
+serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch
+serial-max310x-prevent-infinite-while-loop-in-port-startup.patch
+ftrace-fix-direct_calls-to-use-save_regs-by-default.patch
+powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch
+powerpc-cputable-add-missing-ppc_feature_booke-on-ppc64-book-e.patch
+powerpc-pseries-fix-accuracy-of-stolen-time.patch
+serial-core-introduce-uart_port_tx_flags.patch
+serial-mxs-auart-fix-tx.patch
+x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch
+x86-fpu-stop-relying-on-userspace-for-info-to-fault-in-xsave-buffer.patch
+kvm-x86-make-kvm_req_nmi-request-iff-nmi-pending-for-vcpu.patch
+kvm-x86-pmu-fix-type-length-error-when-reading-pmu-fixed_ctr_ctrl.patch
+x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch
+io_uring-net-fix-multishot-accept-overflow-handling.patch
+mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch
+alsa-hda-realtek-fix-mute-micmute-led-for-hp-mt645.patch
+alsa-hda-conexant-add-quirk-for-sws-js201d.patch
+alsa-hda-realtek-add-ids-for-dell-dual-spk-platform.patch
+nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch
+nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch
--- /dev/null
+From d877550eaf2dc9090d782864c96939397a3c6835 Mon Sep 17 00:00:00 2001
+From: Andrei Vagin <avagin@google.com>
+Date: Mon, 29 Jan 2024 22:36:03 -0800
+Subject: x86/fpu: Stop relying on userspace for info to fault in xsave buffer
+
+From: Andrei Vagin <avagin@google.com>
+
+commit d877550eaf2dc9090d782864c96939397a3c6835 upstream.
+
+Before this change, the expected size of the user space buffer was
+taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed
+from user-space, so it is possible construct a sigreturn frame where:
+
+ * fx_sw->xstate_size is smaller than the size required by valid bits in
+ fx_sw->xfeatures.
+ * user-space unmaps parts of the sigrame fpu buffer so that not all of
+ the buffer required by xrstor is accessible.
+
+In this case, xrstor tries to restore and accesses the unmapped area
+which results in a fault. But fault_in_readable succeeds because buf +
+fx_sw->xstate_size is within the still mapped area, so it goes back and
+tries xrstor again. It will spin in this loop forever.
+
+Instead, fault in the maximum size which can be touched by XRSTOR (taken
+from fpstate->user_size).
+
+[ dhansen: tweak subject / changelog ]
+
+Fixes: fcb3635f5018 ("x86/fpu/signal: Handle #PF in the direct restore path")
+Reported-by: Konstantin Bogomolov <bogomolov@google.com>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Andrei Vagin <avagin@google.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc:stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20240130063603.3392627-1-avagin%40google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/fpu/signal.c | 13 +++++--------
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/kernel/fpu/signal.c
++++ b/arch/x86/kernel/fpu/signal.c
+@@ -274,12 +274,13 @@ static int __restore_fpregs_from_user(vo
+ * Attempt to restore the FPU registers directly from user memory.
+ * Pagefaults are handled and any errors returned are fatal.
+ */
+-static bool restore_fpregs_from_user(void __user *buf, u64 xrestore,
+- bool fx_only, unsigned int size)
++static bool restore_fpregs_from_user(void __user *buf, u64 xrestore, bool fx_only)
+ {
+ struct fpu *fpu = ¤t->thread.fpu;
+ int ret;
+
++ /* Restore enabled features only. */
++ xrestore &= fpu->fpstate->user_xfeatures;
+ retry:
+ fpregs_lock();
+ /* Ensure that XFD is up to date */
+@@ -309,7 +310,7 @@ retry:
+ if (ret != X86_TRAP_PF)
+ return false;
+
+- if (!fault_in_readable(buf, size))
++ if (!fault_in_readable(buf, fpu->fpstate->user_size))
+ goto retry;
+ return false;
+ }
+@@ -339,7 +340,6 @@ static bool __fpu_restore_sig(void __use
+ struct user_i387_ia32_struct env;
+ bool success, fx_only = false;
+ union fpregs_state *fpregs;
+- unsigned int state_size;
+ u64 user_xfeatures = 0;
+
+ if (use_xsave()) {
+@@ -349,17 +349,14 @@ static bool __fpu_restore_sig(void __use
+ return false;
+
+ fx_only = !fx_sw_user.magic1;
+- state_size = fx_sw_user.xstate_size;
+ user_xfeatures = fx_sw_user.xfeatures;
+ } else {
+ user_xfeatures = XFEATURE_MASK_FPSSE;
+- state_size = fpu->fpstate->user_size;
+ }
+
+ if (likely(!ia32_fxstate)) {
+ /* Restore the FPU registers directly from user memory. */
+- return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only,
+- state_size);
++ return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only);
+ }
+
+ /*
--- /dev/null
+From f6a1892585cd19e63c4ef2334e26cd536d5b678d Mon Sep 17 00:00:00 2001
+From: Aleksander Mazur <deweloper@wp.pl>
+Date: Tue, 23 Jan 2024 14:43:00 +0100
+Subject: x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6
+
+From: Aleksander Mazur <deweloper@wp.pl>
+
+commit f6a1892585cd19e63c4ef2334e26cd536d5b678d upstream.
+
+The kernel built with MCRUSOE is unbootable on Transmeta Crusoe. It shows
+the following error message:
+
+ This kernel requires an i686 CPU, but only detected an i586 CPU.
+ Unable to boot - please use a kernel appropriate for your CPU.
+
+Remove MCRUSOE from the condition introduced in commit in Fixes, effectively
+changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the
+CPU family given by CPUID.
+
+ [ bp: Massage commit message. ]
+
+Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig")
+Signed-off-by: Aleksander Mazur <deweloper@wp.pl>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Acked-by: H. Peter Anvin <hpa@zytor.com>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Kconfig.cpu | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/Kconfig.cpu
++++ b/arch/x86/Kconfig.cpu
+@@ -375,7 +375,7 @@ config X86_CMOV
+ config X86_MINIMUM_CPU_FAMILY
+ int
+ default "64" if X86_64
+- default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || MCORE2 || MK7 || MK8)
++ default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCORE2 || MK7 || MK8)
+ default "5" if X86_32 && X86_CMPXCHG64
+ default "4"
+
--- /dev/null
+From d794734c9bbfe22f86686dc2909c25f5ffe1a572 Mon Sep 17 00:00:00 2001
+From: Steve Wahl <steve.wahl@hpe.com>
+Date: Fri, 26 Jan 2024 10:48:41 -0600
+Subject: x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
+
+From: Steve Wahl <steve.wahl@hpe.com>
+
+commit d794734c9bbfe22f86686dc2909c25f5ffe1a572 upstream.
+
+When ident_pud_init() uses only gbpages to create identity maps, large
+ranges of addresses not actually requested can be included in the
+resulting table; a 4K request will map a full GB. On UV systems, this
+ends up including regions that will cause hardware to halt the system
+if accessed (these are marked "reserved" by BIOS). Even processor
+speculation into these regions is enough to trigger the system halt.
+
+Only use gbpages when map creation requests include the full GB page
+of space. Fall back to using smaller 2M pages when only portions of a
+GB page are included in the request.
+
+No attempt is made to coalesce mapping requests. If a request requires
+a map entry at the 2M (pmd) level, subsequent mapping requests within
+the same 1G region will also be at the pmd level, even if adjacent or
+overlapping such requests could have been combined to map a full
+gbpage. Existing usage starts with larger regions and then adds
+smaller regions, so this should not have any great consequence.
+
+[ dhansen: fix up comment formatting, simplifty changelog ]
+
+Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/ident_map.c | 23 ++++++++++++++++++-----
+ 1 file changed, 18 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/mm/ident_map.c
++++ b/arch/x86/mm/ident_map.c
+@@ -26,18 +26,31 @@ static int ident_pud_init(struct x86_map
+ for (; addr < end; addr = next) {
+ pud_t *pud = pud_page + pud_index(addr);
+ pmd_t *pmd;
++ bool use_gbpage;
+
+ next = (addr & PUD_MASK) + PUD_SIZE;
+ if (next > end)
+ next = end;
+
+- if (info->direct_gbpages) {
+- pud_t pudval;
++ /* if this is already a gbpage, this portion is already mapped */
++ if (pud_large(*pud))
++ continue;
++
++ /* Is using a gbpage allowed? */
++ use_gbpage = info->direct_gbpages;
+
+- if (pud_present(*pud))
+- continue;
++ /* Don't use gbpage if it maps more than the requested region. */
++ /* at the begining: */
++ use_gbpage &= ((addr & ~PUD_MASK) == 0);
++ /* ... or at the end: */
++ use_gbpage &= ((next & ~PUD_MASK) == 0);
++
++ /* Never overwrite existing mappings */
++ use_gbpage &= !pud_present(*pud);
++
++ if (use_gbpage) {
++ pud_t pudval;
+
+- addr &= PUD_MASK;
+ pudval = __pud((addr - info->offset) | info->page_flag);
+ set_pud(pud, pudval);
+ continue;
projects / thirdparty / kernel / stable-queue.git / commitdiff
