--- /dev/null
+From fcca6d05ef49d5650514ea1dcfd12e4ae3ff2be6 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Fri, 30 Aug 2024 22:31:54 +0800
+Subject: ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit fcca6d05ef49d5650514ea1dcfd12e4ae3ff2be6 upstream.
+
+Return devm_of_clk_add_hw_provider() in order to transfer the error, if it
+fails due to resource allocation failure or device tree clock provider
+registration failure.
+
+Cc: stable@vger.kernel.org
+Fixes: ebbfabc16d23 ("ASoC: rt5682: Add CCF usage for providing I2S clks")
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Link: https://patch.msgid.link/20240830143154.3448004-1-make24@iscas.ac.cn
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/rt5682.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/sound/soc/codecs/rt5682.c
++++ b/sound/soc/codecs/rt5682.c
+@@ -2903,8 +2903,10 @@ int rt5682_register_dai_clks(struct rt56
+ }
+
+ if (dev->of_node) {
+- devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
++ ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
+ dai_clk_hw);
++ if (ret)
++ return ret;
+ } else {
+ ret = devm_clk_hw_register_clkdev(dev, dai_clk_hw,
+ init.name,
--- /dev/null
+From 07bfa9cdbf3cd2daadfaaba0601f126f45951ffa Mon Sep 17 00:00:00 2001
+From: Leo Ma <hanghong.ma@amd.com>
+Date: Mon, 19 Aug 2024 13:25:27 -0400
+Subject: drm/amd/display: Add HDMI DSC native YCbCr422 support
+
+From: Leo Ma <hanghong.ma@amd.com>
+
+commit 07bfa9cdbf3cd2daadfaaba0601f126f45951ffa upstream.
+
+[WHY && HOW]
+For some HDMI OVT timing, YCbCr422 encoding fails at the DSC
+bandwidth check. The root cause is our DSC policy for timing
+doesn't account for HDMI YCbCr422 native support.
+
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Chris Park <chris.park@amd.com>
+Signed-off-by: Leo Ma <hanghong.ma@amd.com>
+Signed-off-by: Alex Hung <alex.hung@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_mst_types.c | 4 ++--
+ drivers/gpu/drm/amd/display/dc/dc_dsc.h | 3 ++-
+ drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 5 +++--
+ 3 files changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+@@ -1115,7 +1115,7 @@ static int compute_mst_dsc_configs_for_l
+ params[count].num_slices_v = aconnector->dsc_settings.dsc_num_slices_v;
+ params[count].bpp_overwrite = aconnector->dsc_settings.dsc_bits_per_pixel;
+ params[count].compression_possible = stream->sink->dsc_caps.dsc_dec_caps.is_dsc_supported;
+- dc_dsc_get_policy_for_timing(params[count].timing, 0, &dsc_policy);
++ dc_dsc_get_policy_for_timing(params[count].timing, 0, &dsc_policy, dc_link_get_highest_encoding_format(stream->link));
+ if (!dc_dsc_compute_bandwidth_range(
+ stream->sink->ctx->dc->res_pool->dscs[0],
+ stream->sink->ctx->dc->debug.dsc_min_slice_height_override,
+@@ -1586,7 +1586,7 @@ static bool is_dsc_common_config_possibl
+ {
+ struct dc_dsc_policy dsc_policy = {0};
+
+- dc_dsc_get_policy_for_timing(&stream->timing, 0, &dsc_policy);
++ dc_dsc_get_policy_for_timing(&stream->timing, 0, &dsc_policy, dc_link_get_highest_encoding_format(stream->link));
+ dc_dsc_compute_bandwidth_range(stream->sink->ctx->dc->res_pool->dscs[0],
+ stream->sink->ctx->dc->debug.dsc_min_slice_height_override,
+ dsc_policy.min_target_bpp * 16,
+--- a/drivers/gpu/drm/amd/display/dc/dc_dsc.h
++++ b/drivers/gpu/drm/amd/display/dc/dc_dsc.h
+@@ -100,7 +100,8 @@ uint32_t dc_dsc_stream_bandwidth_overhea
+ */
+ void dc_dsc_get_policy_for_timing(const struct dc_crtc_timing *timing,
+ uint32_t max_target_bpp_limit_override_x16,
+- struct dc_dsc_policy *policy);
++ struct dc_dsc_policy *policy,
++ const enum dc_link_encoding_format link_encoding);
+
+ void dc_dsc_policy_set_max_target_bpp_limit(uint32_t limit);
+
+--- a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
++++ b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c
+@@ -861,7 +861,7 @@ static bool setup_dsc_config(
+
+ memset(dsc_cfg, 0, sizeof(struct dc_dsc_config));
+
+- dc_dsc_get_policy_for_timing(timing, options->max_target_bpp_limit_override_x16, &policy);
++ dc_dsc_get_policy_for_timing(timing, options->max_target_bpp_limit_override_x16, &policy, link_encoding);
+ pic_width = timing->h_addressable + timing->h_border_left + timing->h_border_right;
+ pic_height = timing->v_addressable + timing->v_border_top + timing->v_border_bottom;
+
+@@ -1134,7 +1134,8 @@ uint32_t dc_dsc_stream_bandwidth_overhea
+
+ void dc_dsc_get_policy_for_timing(const struct dc_crtc_timing *timing,
+ uint32_t max_target_bpp_limit_override_x16,
+- struct dc_dsc_policy *policy)
++ struct dc_dsc_policy *policy,
++ const enum dc_link_encoding_format link_encoding)
+ {
+ uint32_t bpc = 0;
+
--- /dev/null
+From 8151a6c13111b465dbabe07c19f572f7cbd16fef Mon Sep 17 00:00:00 2001
+From: Fangzhi Zuo <Jerry.Zuo@amd.com>
+Date: Fri, 12 Jul 2024 16:30:03 -0400
+Subject: drm/amd/display: Skip Recompute DSC Params if no Stream on Link
+
+From: Fangzhi Zuo <Jerry.Zuo@amd.com>
+
+commit 8151a6c13111b465dbabe07c19f572f7cbd16fef upstream.
+
+[why]
+Encounter NULL pointer dereference uner mst + dsc setup.
+
+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
+
+[how]
+dsc recompute should be skipped if no mode change detected on the new
+request. If detected, keep checking whether the stream is already on
+current state or not.
+
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
+Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
+Signed-off-by: Wayne Lin <wayne.lin@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_mst_types.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+@@ -1269,6 +1269,9 @@ static bool is_dsc_need_re_compute(
+ if (new_stream_on_link_num == 0)
+ return false;
+
++ if (new_stream_on_link_num == 0)
++ return false;
++
+ /* check current_state if there stream on link but it is not in
+ * new request state
+ */
--- /dev/null
+From eb017f4ea13b1a5ad7f4332279f2e4c67b44bdea Mon Sep 17 00:00:00 2001
+From: Nuno Sa <nuno.sa@analog.com>
+Date: Fri, 20 Sep 2024 09:22:52 +0200
+Subject: Input: adp5588-keys - fix check on return code
+
+From: Nuno Sa <nuno.sa@analog.com>
+
+commit eb017f4ea13b1a5ad7f4332279f2e4c67b44bdea upstream.
+
+During adp5588_setup(), we read all the events to clear the event FIFO.
+However, adp5588_read() just calls i2c_smbus_read_byte_data() which
+returns the byte read in case everything goes well. Hence, we need to
+explicitly check for a negative error code instead of checking for
+something different than 0.
+
+Fixes: e960309ce318 ("Input: adp5588-keys - bail out on returned error")
+Cc: stable@vger.kernel.org
+Signed-off-by: Nuno Sa <nuno.sa@analog.com>
+Link: https://lore.kernel.org/r/20240920-fix-adp5588-err-check-v1-1-81f6e957ef24@analog.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/keyboard/adp5588-keys.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/input/keyboard/adp5588-keys.c
++++ b/drivers/input/keyboard/adp5588-keys.c
+@@ -627,7 +627,7 @@ static int adp5588_setup(struct adp5588_
+
+ for (i = 0; i < KEYP_MAX_EVENT; i++) {
+ ret = adp5588_read(client, KEY_EVENTA);
+- if (ret)
++ if (ret < 0)
+ return ret;
+ }
+
--- /dev/null
+From 01eed86d50af9fab27d876fd677b86259ebe9de3 Mon Sep 17 00:00:00 2001
+From: Werner Sembach <wse@tuxedocomputers.com>
+Date: Tue, 10 Sep 2024 11:40:07 +0200
+Subject: Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line
+
+From: Werner Sembach <wse@tuxedocomputers.com>
+
+commit 01eed86d50af9fab27d876fd677b86259ebe9de3 upstream.
+
+There might be devices out in the wild where the board name is GMxXGxx
+instead of GMxXGxX.
+
+Adding both to be on the safe side.
+
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240910094008.1601230-2-wse@tuxedocomputers.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -1138,6 +1138,13 @@ static const struct dmi_system_id i8042_
+ },
+ {
+ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GMxXGxx"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
++ },
++ {
++ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GMxXGxX"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
--- /dev/null
+From 3870e2850b56306d1d1e435c5a1ccbccd7c59291 Mon Sep 17 00:00:00 2001
+From: Werner Sembach <wse@tuxedocomputers.com>
+Date: Tue, 10 Sep 2024 11:40:08 +0200
+Subject: Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table
+
+From: Werner Sembach <wse@tuxedocomputers.com>
+
+commit 3870e2850b56306d1d1e435c5a1ccbccd7c59291 upstream.
+
+The Gen6 devices have the same problem and the same Solution as the Gen5
+ones.
+
+Some TongFang barebones have touchpad and/or keyboard issues after
+suspend, fixable with nomux + reset + noloop + nopnp. Luckily, none of
+them have an external PS/2 port so this can safely be set for all of
+them.
+
+I'm not entirely sure if every device listed really needs all four quirks,
+but after testing and production use, no negative effects could be
+observed when setting all four.
+
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240910094008.1601230-3-wse@tuxedocomputers.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -1143,6 +1143,13 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
+ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
+ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GMxHGxx"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
++ },
+ /*
+ * A lot of modern Clevo barebones have touchpad and/or keyboard issues
+ * after suspend fixable with nomux + reset + noloop + nopnp. Luckily,
--- /dev/null
+From e06edf96dea065dd1d9df695bf8b92784992333e Mon Sep 17 00:00:00 2001
+From: Werner Sembach <wse@tuxedocomputers.com>
+Date: Thu, 5 Sep 2024 18:48:51 +0200
+Subject: Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table
+
+From: Werner Sembach <wse@tuxedocomputers.com>
+
+commit e06edf96dea065dd1d9df695bf8b92784992333e upstream.
+
+Some TongFang barebones have touchpad and/or keyboard issues after
+suspend, fixable with nomux + reset + noloop + nopnp. Luckily, none of
+them have an external PS/2 port so this can safely be set for all of
+them.
+
+I'm not entirely sure if every device listed really needs all four quirks,
+but after testing and production use, no negative effects could be
+observed when setting all four.
+
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240905164851.771578-1-wse@tuxedocomputers.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 23 +++++++++++++++++++++++
+ 1 file changed, 23 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -1121,6 +1121,29 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOLOOP)
+ },
+ /*
++ * Some TongFang barebones have touchpad and/or keyboard issues after
++ * suspend fixable with nomux + reset + noloop + nopnp. Luckily, none of
++ * them have an external PS/2 port so this can safely be set for all of
++ * them.
++ * TongFang barebones come with board_vendor and/or system_vendor set to
++ * a different value for each individual reseller. The only somewhat
++ * universal way to identify them is by board_name.
++ */
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GM6XGxX"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "GMxXGxX"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
++ },
++ /*
+ * A lot of modern Clevo barebones have touchpad and/or keyboard issues
+ * after suspend fixable with nomux + reset + noloop + nopnp. Luckily,
+ * none of them have an external PS/2 port so this can safely be set for
--- /dev/null
+From 8f6887349b2f829a4121c518aeb064fc922714e4 Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 27 Aug 2024 13:46:45 -0300
+Subject: iommufd: Protect against overflow of ALIGN() during iova allocation
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 8f6887349b2f829a4121c518aeb064fc922714e4 upstream.
+
+Userspace can supply an iova and uptr such that the target iova alignment
+becomes really big and ALIGN() overflows which corrupts the selected area
+range during allocation. CONFIG_IOMMUFD_TEST can detect this:
+
+ WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
+ WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
+ Modules linked in:
+ CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0
+ Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
+ RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
+ RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
+ Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38
+ RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293
+ RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00
+ RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000
+ RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942
+ R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010
+ R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00
+ FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ Call Trace:
+ <TASK>
+ iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274
+ iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421
+ vfs_ioctl fs/ioctl.c:51 [inline]
+ __do_sys_ioctl fs/ioctl.c:907 [inline]
+ __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
+ do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+ do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Cap the automatic alignment to the huge page size, which is probably a
+better idea overall. Huge automatic alignments can fragment and chew up
+the available IOVA space without any reason.
+
+Link: https://patch.msgid.link/r/0-v1-8009738b9891+1f7-iommufd_align_overflow_jgg@nvidia.com
+Cc: stable@vger.kernel.org
+Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping")
+Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
+Reported-by: syzbot+16073ebbc4c64b819b47@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/r/000000000000388410061a74f014@google.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/iommufd/io_pagetable.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/iommu/iommufd/io_pagetable.c
++++ b/drivers/iommu/iommufd/io_pagetable.c
+@@ -111,6 +111,7 @@ static int iopt_alloc_iova(struct io_pag
+ unsigned long page_offset = uptr % PAGE_SIZE;
+ struct interval_tree_double_span_iter used_span;
+ struct interval_tree_span_iter allowed_span;
++ unsigned long max_alignment = PAGE_SIZE;
+ unsigned long iova_alignment;
+
+ lockdep_assert_held(&iopt->iova_rwsem);
+@@ -130,6 +131,13 @@ static int iopt_alloc_iova(struct io_pag
+ roundup_pow_of_two(length),
+ 1UL << __ffs64(uptr));
+
++#ifdef CONFIG_TRANSPARENT_HUGEPAGE
++ max_alignment = HPAGE_SIZE;
++#endif
++ /* Protect against ALIGN() overflow */
++ if (iova_alignment >= max_alignment)
++ iova_alignment = max_alignment;
++
+ if (iova_alignment < iopt->iova_alignment)
+ return -EINVAL;
+
--- /dev/null
+From f26a525b77e040d584e967369af1e018d2d59112 Mon Sep 17 00:00:00 2001
+From: Snehal Koukuntla <snehalreddy@google.com>
+Date: Mon, 9 Sep 2024 18:01:54 +0000
+Subject: KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer
+
+From: Snehal Koukuntla <snehalreddy@google.com>
+
+commit f26a525b77e040d584e967369af1e018d2d59112 upstream.
+
+When we share memory through FF-A and the description of the buffers
+exceeds the size of the mapped buffer, the fragmentation API is used.
+The fragmentation API allows specifying chunks of descriptors in subsequent
+FF-A fragment calls and no upper limit has been established for this.
+The entire memory region transferred is identified by a handle which can be
+used to reclaim the transferred memory.
+To be able to reclaim the memory, the description of the buffers has to fit
+in the ffa_desc_buf.
+Add a bounds check on the FF-A sharing path to prevent the memory reclaim
+from failing.
+
+Also do_ffa_mem_xfer() does not need __always_inline, except for the
+BUILD_BUG_ON() aspect, which gets moved to a macro.
+
+[maz: fixed the BUILD_BUG_ON() breakage with LLVM, thanks to Wei-Lin Chang
+ for the timely report]
+
+Fixes: 634d90cf0ac65 ("KVM: arm64: Handle FFA_MEM_LEND calls from the host")
+Cc: stable@vger.kernel.org
+Reviewed-by: Sebastian Ene <sebastianene@google.com>
+Signed-off-by: Snehal Koukuntla <snehalreddy@google.com>
+Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
+Link: https://lore.kernel.org/r/20240909180154.3267939-1-snehalreddy@google.com
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/hyp/nvhe/ffa.c | 21 +++++++++++++++------
+ 1 file changed, 15 insertions(+), 6 deletions(-)
+
+--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
++++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
+@@ -415,9 +415,9 @@ out:
+ return;
+ }
+
+-static __always_inline void do_ffa_mem_xfer(const u64 func_id,
+- struct arm_smccc_res *res,
+- struct kvm_cpu_context *ctxt)
++static void __do_ffa_mem_xfer(const u64 func_id,
++ struct arm_smccc_res *res,
++ struct kvm_cpu_context *ctxt)
+ {
+ DECLARE_REG(u32, len, ctxt, 1);
+ DECLARE_REG(u32, fraglen, ctxt, 2);
+@@ -428,9 +428,6 @@ static __always_inline void do_ffa_mem_x
+ u32 offset, nr_ranges;
+ int ret = 0;
+
+- BUILD_BUG_ON(func_id != FFA_FN64_MEM_SHARE &&
+- func_id != FFA_FN64_MEM_LEND);
+-
+ if (addr_mbz || npages_mbz || fraglen > len ||
+ fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+@@ -449,6 +446,11 @@ static __always_inline void do_ffa_mem_x
+ goto out_unlock;
+ }
+
++ if (len > ffa_desc_buf.len) {
++ ret = FFA_RET_NO_MEMORY;
++ goto out_unlock;
++ }
++
+ buf = hyp_buffers.tx;
+ memcpy(buf, host_buffers.tx, fraglen);
+
+@@ -498,6 +500,13 @@ err_unshare:
+ goto out_unlock;
+ }
+
++#define do_ffa_mem_xfer(fid, res, ctxt) \
++ do { \
++ BUILD_BUG_ON((fid) != FFA_FN64_MEM_SHARE && \
++ (fid) != FFA_FN64_MEM_LEND); \
++ __do_ffa_mem_xfer((fid), (res), (ctxt)); \
++ } while (0);
++
+ static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
+ struct kvm_cpu_context *ctxt)
+ {
--- /dev/null
+From 44d17459626052a2390457e550a12cb973506b2f Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 29 Aug 2024 21:35:51 -0700
+Subject: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 44d17459626052a2390457e550a12cb973506b2f upstream.
+
+Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock
+on x86 due to a chain of locks and SRCU synchronizations. Translating the
+below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on
+CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the
+fairness of r/w semaphores).
+
+ CPU0 CPU1 CPU2
+1 lock(&kvm->slots_lock);
+2 lock(&vcpu->mutex);
+3 lock(&kvm->srcu);
+4 lock(cpu_hotplug_lock);
+5 lock(kvm_lock);
+6 lock(&kvm->slots_lock);
+7 lock(cpu_hotplug_lock);
+8 sync(&kvm->srcu);
+
+Note, there are likely more potential deadlocks in KVM x86, e.g. the same
+pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with
+__kvmclock_cpufreq_notifier():
+
+ cpuhp_cpufreq_online()
+ |
+ -> cpufreq_online()
+ |
+ -> cpufreq_gov_performance_limits()
+ |
+ -> __cpufreq_driver_target()
+ |
+ -> __target_index()
+ |
+ -> cpufreq_freq_transition_begin()
+ |
+ -> cpufreq_notify_transition()
+ |
+ -> ... __kvmclock_cpufreq_notifier()
+
+But, actually triggering such deadlocks is beyond rare due to the
+combination of dependencies and timings involved. E.g. the cpufreq
+notifier is only used on older CPUs without a constant TSC, mucking with
+the NX hugepage mitigation while VMs are running is very uncommon, and
+doing so while also onlining/offlining a CPU (necessary to generate
+contention on cpu_hotplug_lock) would be even more unusual.
+
+The most robust solution to the general cpu_hotplug_lock issue is likely
+to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq
+notifier doesn't to take kvm_lock. For now, settle for fixing the most
+blatant deadlock, as switching to an RCU-protected list is a much more
+involved change, but add a comment in locking.rst to call out that care
+needs to be taken when walking holding kvm_lock and walking vm_list.
+
+ ======================================================
+ WARNING: possible circular locking dependency detected
+ 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O
+ ------------------------------------------------------
+ tee/35048 is trying to acquire lock:
+ ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]
+
+ but task is already holding lock:
+ ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #3 (kvm_lock){+.+.}-{3:3}:
+ __mutex_lock+0x6a/0xb40
+ mutex_lock_nested+0x1f/0x30
+ kvm_dev_ioctl+0x4fb/0xe50 [kvm]
+ __se_sys_ioctl+0x7b/0xd0
+ __x64_sys_ioctl+0x21/0x30
+ x64_sys_call+0x15d0/0x2e60
+ do_syscall_64+0x83/0x160
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+ -> #2 (cpu_hotplug_lock){++++}-{0:0}:
+ cpus_read_lock+0x2e/0xb0
+ static_key_slow_inc+0x16/0x30
+ kvm_lapic_set_base+0x6a/0x1c0 [kvm]
+ kvm_set_apic_base+0x8f/0xe0 [kvm]
+ kvm_set_msr_common+0x9ae/0xf80 [kvm]
+ vmx_set_msr+0xa54/0xbe0 [kvm_intel]
+ __kvm_set_msr+0xb6/0x1a0 [kvm]
+ kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]
+ kvm_vcpu_ioctl+0x485/0x5b0 [kvm]
+ __se_sys_ioctl+0x7b/0xd0
+ __x64_sys_ioctl+0x21/0x30
+ x64_sys_call+0x15d0/0x2e60
+ do_syscall_64+0x83/0x160
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+ -> #1 (&kvm->srcu){.+.+}-{0:0}:
+ __synchronize_srcu+0x44/0x1a0
+ synchronize_srcu_expedited+0x21/0x30
+ kvm_swap_active_memslots+0x110/0x1c0 [kvm]
+ kvm_set_memslot+0x360/0x620 [kvm]
+ __kvm_set_memory_region+0x27b/0x300 [kvm]
+ kvm_vm_ioctl_set_memory_region+0x43/0x60 [kvm]
+ kvm_vm_ioctl+0x295/0x650 [kvm]
+ __se_sys_ioctl+0x7b/0xd0
+ __x64_sys_ioctl+0x21/0x30
+ x64_sys_call+0x15d0/0x2e60
+ do_syscall_64+0x83/0x160
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+ -> #0 (&kvm->slots_lock){+.+.}-{3:3}:
+ __lock_acquire+0x15ef/0x2e30
+ lock_acquire+0xe0/0x260
+ __mutex_lock+0x6a/0xb40
+ mutex_lock_nested+0x1f/0x30
+ set_nx_huge_pages+0x179/0x1e0 [kvm]
+ param_attr_store+0x93/0x100
+ module_attr_store+0x22/0x40
+ sysfs_kf_write+0x81/0xb0
+ kernfs_fop_write_iter+0x133/0x1d0
+ vfs_write+0x28d/0x380
+ ksys_write+0x70/0xe0
+ __x64_sys_write+0x1f/0x30
+ x64_sys_call+0x281b/0x2e60
+ do_syscall_64+0x83/0x160
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+Cc: Chao Gao <chao.gao@intel.com>
+Fixes: 0bf50497f03b ("KVM: Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock")
+Cc: stable@vger.kernel.org
+Reviewed-by: Kai Huang <kai.huang@intel.com>
+Acked-by: Kai Huang <kai.huang@intel.com>
+Tested-by: Farrah Chen <farrah.chen@intel.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-ID: <20240830043600.127750-2-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/virt/kvm/locking.rst | 32 +++++++++++++++++++++++---------
+ virt/kvm/kvm_main.c | 31 ++++++++++++++++---------------
+ 2 files changed, 39 insertions(+), 24 deletions(-)
+
+--- a/Documentation/virt/kvm/locking.rst
++++ b/Documentation/virt/kvm/locking.rst
+@@ -9,7 +9,7 @@ KVM Lock Overview
+
+ The acquisition orders for mutexes are as follows:
+
+-- cpus_read_lock() is taken outside kvm_lock
++- cpus_read_lock() is taken outside kvm_lock and kvm_usage_lock
+
+ - kvm->lock is taken outside vcpu->mutex
+
+@@ -24,6 +24,12 @@ The acquisition orders for mutexes are a
+ are taken on the waiting side when modifying memslots, so MMU notifiers
+ must not take either kvm->slots_lock or kvm->slots_arch_lock.
+
++cpus_read_lock() vs kvm_lock:
++- Taking cpus_read_lock() outside of kvm_lock is problematic, despite that
++ being the official ordering, as it is quite easy to unknowingly trigger
++ cpus_read_lock() while holding kvm_lock. Use caution when walking vm_list,
++ e.g. avoid complex operations when possible.
++
+ For SRCU:
+
+ - ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
+@@ -228,10 +234,17 @@ time it will be set using the Dirty trac
+ :Type: mutex
+ :Arch: any
+ :Protects: - vm_list
+- - kvm_usage_count
++
++``kvm_usage_lock``
++^^^^^^^^^^^^^^^^^^
++
++:Type: mutex
++:Arch: any
++:Protects: - kvm_usage_count
+ - hardware virtualization enable/disable
+-:Comment: KVM also disables CPU hotplug via cpus_read_lock() during
+- enable/disable.
++:Comment: Exists because using kvm_lock leads to deadlock (see earlier comment
++ on cpus_read_lock() vs kvm_lock). Note, KVM also disables CPU hotplug via
++ cpus_read_lock() when enabling/disabling virtualization.
+
+ ``kvm->mn_invalidate_lock``
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+@@ -291,11 +304,12 @@ time it will be set using the Dirty trac
+ wakeup.
+
+ ``vendor_module_lock``
+-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++^^^^^^^^^^^^^^^^^^^^^^
+ :Type: mutex
+ :Arch: x86
+ :Protects: loading a vendor module (kvm_amd or kvm_intel)
+-:Comment: Exists because using kvm_lock leads to deadlock. cpu_hotplug_lock is
+- taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks, and
+- many operations need to take cpu_hotplug_lock when loading a vendor module,
+- e.g. updating static calls.
++:Comment: Exists because using kvm_lock leads to deadlock. kvm_lock is taken
++ in notifiers, e.g. __kvmclock_cpufreq_notifier(), that may be invoked while
++ cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and many
++ operations need to take cpu_hotplug_lock when loading a vendor module, e.g.
++ updating static calls.
+--- a/virt/kvm/kvm_main.c
++++ b/virt/kvm/kvm_main.c
+@@ -5174,6 +5174,7 @@ __visible bool kvm_rebooting;
+ EXPORT_SYMBOL_GPL(kvm_rebooting);
+
+ static DEFINE_PER_CPU(bool, hardware_enabled);
++static DEFINE_MUTEX(kvm_usage_lock);
+ static int kvm_usage_count;
+
+ static int __hardware_enable_nolock(void)
+@@ -5206,10 +5207,10 @@ static int kvm_online_cpu(unsigned int c
+ * be enabled. Otherwise running VMs would encounter unrecoverable
+ * errors when scheduled to this CPU.
+ */
+- mutex_lock(&kvm_lock);
++ mutex_lock(&kvm_usage_lock);
+ if (kvm_usage_count)
+ ret = __hardware_enable_nolock();
+- mutex_unlock(&kvm_lock);
++ mutex_unlock(&kvm_usage_lock);
+ return ret;
+ }
+
+@@ -5229,10 +5230,10 @@ static void hardware_disable_nolock(void
+
+ static int kvm_offline_cpu(unsigned int cpu)
+ {
+- mutex_lock(&kvm_lock);
++ mutex_lock(&kvm_usage_lock);
+ if (kvm_usage_count)
+ hardware_disable_nolock(NULL);
+- mutex_unlock(&kvm_lock);
++ mutex_unlock(&kvm_usage_lock);
+ return 0;
+ }
+
+@@ -5248,9 +5249,9 @@ static void hardware_disable_all_nolock(
+ static void hardware_disable_all(void)
+ {
+ cpus_read_lock();
+- mutex_lock(&kvm_lock);
++ mutex_lock(&kvm_usage_lock);
+ hardware_disable_all_nolock();
+- mutex_unlock(&kvm_lock);
++ mutex_unlock(&kvm_usage_lock);
+ cpus_read_unlock();
+ }
+
+@@ -5281,7 +5282,7 @@ static int hardware_enable_all(void)
+ * enable hardware multiple times.
+ */
+ cpus_read_lock();
+- mutex_lock(&kvm_lock);
++ mutex_lock(&kvm_usage_lock);
+
+ r = 0;
+
+@@ -5295,7 +5296,7 @@ static int hardware_enable_all(void)
+ }
+ }
+
+- mutex_unlock(&kvm_lock);
++ mutex_unlock(&kvm_usage_lock);
+ cpus_read_unlock();
+
+ return r;
+@@ -5323,13 +5324,13 @@ static int kvm_suspend(void)
+ {
+ /*
+ * Secondary CPUs and CPU hotplug are disabled across the suspend/resume
+- * callbacks, i.e. no need to acquire kvm_lock to ensure the usage count
+- * is stable. Assert that kvm_lock is not held to ensure the system
+- * isn't suspended while KVM is enabling hardware. Hardware enabling
+- * can be preempted, but the task cannot be frozen until it has dropped
+- * all locks (userspace tasks are frozen via a fake signal).
++ * callbacks, i.e. no need to acquire kvm_usage_lock to ensure the usage
++ * count is stable. Assert that kvm_usage_lock is not held to ensure
++ * the system isn't suspended while KVM is enabling hardware. Hardware
++ * enabling can be preempted, but the task cannot be frozen until it has
++ * dropped all locks (userspace tasks are frozen via a fake signal).
+ */
+- lockdep_assert_not_held(&kvm_lock);
++ lockdep_assert_not_held(&kvm_usage_lock);
+ lockdep_assert_irqs_disabled();
+
+ if (kvm_usage_count)
+@@ -5339,7 +5340,7 @@ static int kvm_suspend(void)
+
+ static void kvm_resume(void)
+ {
+- lockdep_assert_not_held(&kvm_lock);
++ lockdep_assert_not_held(&kvm_usage_lock);
+ lockdep_assert_irqs_disabled();
+
+ if (kvm_usage_count)
--- /dev/null
+From 71bf395a276f0578d19e0ae137a7d1d816d08e0e Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Fri, 19 Jul 2024 16:50:58 -0700
+Subject: KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 71bf395a276f0578d19e0ae137a7d1d816d08e0e upstream.
+
+Inject a #GP on a WRMSR(ICR) that attempts to set any reserved bits that
+are must-be-zero on both Intel and AMD, i.e. any reserved bits other than
+the BUSY bit, which Intel ignores and basically says is undefined.
+
+KVM's xapic_state_test selftest has been fudging the bug since commit
+4b88b1a518b3 ("KVM: selftests: Enhance handling WRMSR ICR register in
+x2APIC mode"), which essentially removed the testcase instead of fixing
+the bug.
+
+WARN if the nodecode path triggers a #GP, as the CPU is supposed to check
+reserved bits for ICR when it's partially virtualized.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240719235107.3023592-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/lapic.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -2460,7 +2460,7 @@ void kvm_apic_write_nodecode(struct kvm_
+ * maybe-unecessary write, and both are in the noise anyways.
+ */
+ if (apic_x2apic_mode(apic) && offset == APIC_ICR)
+- kvm_x2apic_icr_write(apic, kvm_lapic_get_reg64(apic, APIC_ICR));
++ WARN_ON_ONCE(kvm_x2apic_icr_write(apic, kvm_lapic_get_reg64(apic, APIC_ICR)));
+ else
+ kvm_lapic_reg_write(apic, offset, kvm_lapic_get_reg(apic, offset));
+ }
+@@ -3153,8 +3153,21 @@ int kvm_lapic_set_vapic_addr(struct kvm_
+ return 0;
+ }
+
++#define X2APIC_ICR_RESERVED_BITS (GENMASK_ULL(31, 20) | GENMASK_ULL(17, 16) | BIT(13))
++
+ int kvm_x2apic_icr_write(struct kvm_lapic *apic, u64 data)
+ {
++ if (data & X2APIC_ICR_RESERVED_BITS)
++ return 1;
++
++ /*
++ * The BUSY bit is reserved on both Intel and AMD in x2APIC mode, but
++ * only AMD requires it to be zero, Intel essentially just ignores the
++ * bit. And if IPI virtualization (Intel) or x2AVIC (AMD) is enabled,
++ * the CPU performs the reserved bits checks, i.e. the underlying CPU
++ * behavior will "win". Arbitrarily clear the BUSY bit, as there is no
++ * sane way to provide consistent behavior with respect to hardware.
++ */
+ data &= ~APIC_ICR_BUSY;
+
+ kvm_apic_send_ipi(apic, (u32)data, (u32)(data >> 32));
--- /dev/null
+From d33234342f8b468e719e05649fd26549fb37ef8a Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Fri, 19 Jul 2024 16:50:59 -0700
+Subject: KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit d33234342f8b468e719e05649fd26549fb37ef8a upstream.
+
+Hoist kvm_x2apic_icr_write() above kvm_apic_write_nodecode() so that a
+local helper to _read_ the x2APIC ICR can be added and used in the
+nodecode path without needing a forward declaration.
+
+No functional change intended.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240719235107.3023592-3-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/lapic.c | 46 +++++++++++++++++++++++-----------------------
+ 1 file changed, 23 insertions(+), 23 deletions(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -2443,6 +2443,29 @@ void kvm_lapic_set_eoi(struct kvm_vcpu *
+ }
+ EXPORT_SYMBOL_GPL(kvm_lapic_set_eoi);
+
++#define X2APIC_ICR_RESERVED_BITS (GENMASK_ULL(31, 20) | GENMASK_ULL(17, 16) | BIT(13))
++
++int kvm_x2apic_icr_write(struct kvm_lapic *apic, u64 data)
++{
++ if (data & X2APIC_ICR_RESERVED_BITS)
++ return 1;
++
++ /*
++ * The BUSY bit is reserved on both Intel and AMD in x2APIC mode, but
++ * only AMD requires it to be zero, Intel essentially just ignores the
++ * bit. And if IPI virtualization (Intel) or x2AVIC (AMD) is enabled,
++ * the CPU performs the reserved bits checks, i.e. the underlying CPU
++ * behavior will "win". Arbitrarily clear the BUSY bit, as there is no
++ * sane way to provide consistent behavior with respect to hardware.
++ */
++ data &= ~APIC_ICR_BUSY;
++
++ kvm_apic_send_ipi(apic, (u32)data, (u32)(data >> 32));
++ kvm_lapic_set_reg64(apic, APIC_ICR, data);
++ trace_kvm_apic_write(APIC_ICR, data);
++ return 0;
++}
++
+ /* emulate APIC access in a trap manner */
+ void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset)
+ {
+@@ -3153,29 +3176,6 @@ int kvm_lapic_set_vapic_addr(struct kvm_
+ return 0;
+ }
+
+-#define X2APIC_ICR_RESERVED_BITS (GENMASK_ULL(31, 20) | GENMASK_ULL(17, 16) | BIT(13))
+-
+-int kvm_x2apic_icr_write(struct kvm_lapic *apic, u64 data)
+-{
+- if (data & X2APIC_ICR_RESERVED_BITS)
+- return 1;
+-
+- /*
+- * The BUSY bit is reserved on both Intel and AMD in x2APIC mode, but
+- * only AMD requires it to be zero, Intel essentially just ignores the
+- * bit. And if IPI virtualization (Intel) or x2AVIC (AMD) is enabled,
+- * the CPU performs the reserved bits checks, i.e. the underlying CPU
+- * behavior will "win". Arbitrarily clear the BUSY bit, as there is no
+- * sane way to provide consistent behavior with respect to hardware.
+- */
+- data &= ~APIC_ICR_BUSY;
+-
+- kvm_apic_send_ipi(apic, (u32)data, (u32)(data >> 32));
+- kvm_lapic_set_reg64(apic, APIC_ICR, data);
+- trace_kvm_apic_write(APIC_ICR, data);
+- return 0;
+-}
+-
+ static int kvm_lapic_msr_read(struct kvm_lapic *apic, u32 reg, u64 *data)
+ {
+ u32 low;
--- /dev/null
+From 8037ac08c2bbb3186f83a5a924f52d1048dbaec5 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Fri, 9 Aug 2024 14:24:46 +0100
+Subject: PCI: Clear the LBMS bit after a link retrain
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 8037ac08c2bbb3186f83a5a924f52d1048dbaec5 upstream.
+
+The LBMS bit, where implemented, is set by hardware either in response
+to the completion of retraining caused by writing 1 to the Retrain Link
+bit or whenever hardware has changed the link speed or width in attempt
+to correct unreliable link operation. It is never cleared by hardware
+other than by software writing 1 to the bit position in the Link Status
+register and we never do such a write.
+
+We currently have two places, namely apply_bad_link_workaround() and
+pcie_failed_link_retrain() in drivers/pci/controller/dwc/pcie-tegra194.c
+and drivers/pci/quirks.c respectively where we check the state of the LBMS
+bit and neither is interested in the state of the bit resulting from the
+completion of retraining, both check for a link fault.
+
+And in particular pcie_failed_link_retrain() causes issues consequently, by
+trying to retrain a link where there's no downstream device anymore and the
+state of 1 in the LBMS bit has been retained from when there was a device
+downstream that has since been removed.
+
+Clear the LBMS bit then at the conclusion of pcie_retrain_link(), so that
+we have a single place that controls it and that our code can track link
+speed or width changes resulting from unreliable link operation.
+
+Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091133140.61955@angie.orcam.me.uk
+Reported-by: Matthew W Carlis <mattc@purestorage.com>
+Link: https://lore.kernel.org/r/20240806000659.30859-1-mattc@purestorage.com/
+Link: https://lore.kernel.org/r/20240722193407.23255-1-mattc@purestorage.com/
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Cc: <stable@vger.kernel.org> # v6.5+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -5017,7 +5017,15 @@ int pcie_retrain_link(struct pci_dev *pd
+ pcie_capability_clear_word(pdev, PCI_EXP_LNKCTL, PCI_EXP_LNKCTL_RL);
+ }
+
+- return pcie_wait_for_link_status(pdev, use_lt, !use_lt);
++ rc = pcie_wait_for_link_status(pdev, use_lt, !use_lt);
++
++ /*
++ * Clear LBMS after a manual retrain so that the bit can be used
++ * to track link speed or width changes made by hardware itself
++ * in attempt to correct unreliable link operation.
++ */
++ pcie_capability_write_word(pdev, PCI_EXP_LNKSTA, PCI_EXP_LNKSTA_LBMS);
++ return rc;
+ }
+
+ /**
--- /dev/null
+From 712e49c967064a3a7a5738c6f65ac540a3f6a1df Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Fri, 9 Aug 2024 14:24:56 +0100
+Subject: PCI: Correct error reporting with PCIe failed link retraining
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 712e49c967064a3a7a5738c6f65ac540a3f6a1df upstream.
+
+Only return successful completion status from pcie_failed_link_retrain() if
+retraining has actually been done, preventing excessive delays from being
+triggered at call sites in a hope that communication will finally be
+established with the downstream device where in fact nothing has been done
+about the link in question that would justify such a hope.
+
+Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091133260.61955@angie.orcam.me.uk
+Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Cc: <stable@vger.kernel.org> # v6.5+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -78,7 +78,8 @@
+ * again to remove any residual state, ignoring the result as it's supposed
+ * to fail anyway.
+ *
+- * Return TRUE if the link has been successfully retrained, otherwise FALSE.
++ * Return TRUE if the link has been successfully retrained. Return FALSE
++ * if retraining was not needed or we attempted a retrain and it failed.
+ */
+ bool pcie_failed_link_retrain(struct pci_dev *dev)
+ {
+@@ -87,6 +88,7 @@ bool pcie_failed_link_retrain(struct pci
+ {}
+ };
+ u16 lnksta, lnkctl2;
++ bool ret = false;
+
+ if (!pci_is_pcie(dev) || !pcie_downstream_port(dev) ||
+ !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting)
+@@ -104,7 +106,8 @@ bool pcie_failed_link_retrain(struct pci
+ lnkctl2 |= PCI_EXP_LNKCTL2_TLS_2_5GT;
+ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2, lnkctl2);
+
+- if (pcie_retrain_link(dev, false)) {
++ ret = pcie_retrain_link(dev, false) == 0;
++ if (!ret) {
+ pci_info(dev, "retraining failed\n");
+ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2,
+ oldlnkctl2);
+@@ -126,13 +129,14 @@ bool pcie_failed_link_retrain(struct pci
+ lnkctl2 |= lnkcap & PCI_EXP_LNKCAP_SLS;
+ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2, lnkctl2);
+
+- if (pcie_retrain_link(dev, false)) {
++ ret = pcie_retrain_link(dev, false) == 0;
++ if (!ret) {
+ pci_info(dev, "retraining failed\n");
+ return false;
+ }
+ }
+
+- return true;
++ return ret;
+ }
+
+ static ktime_t fixup_debug_start(struct pci_dev *dev,
--- /dev/null
+From 03f84b3baba7836bdfc162c19288d5ce1aa92890 Mon Sep 17 00:00:00 2001
+From: Siddharth Vadapalli <s-vadapalli@ti.com>
+Date: Tue, 27 Aug 2024 17:54:21 +0530
+Subject: PCI: dra7xx: Fix threaded IRQ request for "dra7xx-pcie-main" IRQ
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Siddharth Vadapalli <s-vadapalli@ti.com>
+
+commit 03f84b3baba7836bdfc162c19288d5ce1aa92890 upstream.
+
+Commit da87d35a6e51 ("PCI: dra7xx: Use threaded IRQ handler for
+"dra7xx-pcie-main" IRQ") switched from devm_request_irq() to
+devm_request_threaded_irq() for the "dra7xx-pcie-main" interrupt.
+
+Since the primary handler was set to NULL, the "IRQF_ONESHOT" flag
+should have also been set. Fix this.
+
+Fixes: da87d35a6e51 ("PCI: dra7xx: Use threaded IRQ handler for "dra7xx-pcie-main" IRQ")
+Suggested-by: Vignesh Raghavendra <vigneshr@ti.com>
+Link: https://lore.kernel.org/linux-pci/20240827122422.985547-2-s-vadapalli@ti.com
+Reported-by: Udit Kumar <u-kumar1@ti.com>
+Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Kevin Hilman <khilman@baylibre.com>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/dwc/pci-dra7xx.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/controller/dwc/pci-dra7xx.c
++++ b/drivers/pci/controller/dwc/pci-dra7xx.c
+@@ -841,7 +841,8 @@ static int dra7xx_pcie_probe(struct plat
+ dra7xx->mode = mode;
+
+ ret = devm_request_threaded_irq(dev, irq, NULL, dra7xx_pcie_irq_handler,
+- IRQF_SHARED, "dra7xx-pcie-main", dra7xx);
++ IRQF_SHARED | IRQF_ONESHOT,
++ "dra7xx-pcie-main", dra7xx);
+ if (ret) {
+ dev_err(dev, "failed to request irq\n");
+ goto err_gpio;
--- /dev/null
+From 5b04d44d5c74e4d8aab1678496b84700b4b343fe Mon Sep 17 00:00:00 2001
+From: Frank Li <Frank.Li@nxp.com>
+Date: Mon, 29 Jul 2024 16:18:10 -0400
+Subject: PCI: imx6: Fix missing call to phy_power_off() in error handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Frank Li <Frank.Li@nxp.com>
+
+commit 5b04d44d5c74e4d8aab1678496b84700b4b343fe upstream.
+
+Fix missing call to phy_power_off() in the error path of
+imx6_pcie_host_init(). Remove unnecessary check for imx6_pcie->phy
+as the PHY API already handles NULL pointers.
+
+Fixes: cbcf8722b523 ("phy: freescale: imx8m-pcie: Fix the wrong order of phy_init() and phy_power_on()")
+Link: https://lore.kernel.org/linux-pci/20240729-pci2_upstream-v8-3-b68ee5ef2b4d@nxp.com
+Signed-off-by: Frank Li <Frank.Li@nxp.com>
+[kwilczynski: commit log]
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Cc: <stable@vger.kernel.org> # 6.1+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/dwc/pci-imx6.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/controller/dwc/pci-imx6.c
++++ b/drivers/pci/controller/dwc/pci-imx6.c
+@@ -997,7 +997,7 @@ static int imx6_pcie_host_init(struct dw
+ ret = phy_power_on(imx6_pcie->phy);
+ if (ret) {
+ dev_err(dev, "waiting for PHY ready timeout!\n");
+- goto err_phy_off;
++ goto err_phy_exit;
+ }
+ }
+
+@@ -1012,8 +1012,9 @@ static int imx6_pcie_host_init(struct dw
+ return 0;
+
+ err_phy_off:
+- if (imx6_pcie->phy)
+- phy_exit(imx6_pcie->phy);
++ phy_power_off(imx6_pcie->phy);
++err_phy_exit:
++ phy_exit(imx6_pcie->phy);
+ err_clk_disable:
+ imx6_pcie_clk_disable(imx6_pcie);
+ err_reg_disable:
--- /dev/null
+From f68dea13405c94381d08f42dbf0416261622bdad Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Fri, 9 Aug 2024 14:24:51 +0100
+Subject: PCI: Revert to the original speed after PCIe failed link retraining
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit f68dea13405c94381d08f42dbf0416261622bdad upstream.
+
+When `pcie_failed_link_retrain' has failed to retrain the link by hand
+it leaves the link speed restricted to 2.5GT/s, which will then affect
+any device that has been plugged in later on, which may not suffer from
+the problem that caused the speed restriction to have been attempted.
+Consequently such a downstream device will suffer from an unnecessary
+communication throughput limitation and therefore performance loss.
+
+Remove the speed restriction then and revert the Link Control 2 register
+to its original state if link retraining with the speed restriction in
+place has failed. Retrain the link again afterwards so as to remove any
+residual state, waiting on LT rather than DLLLA to avoid an excessive
+delay and ignoring the result as this training is supposed to fail
+anyway.
+
+Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
+Link: https://lore.kernel.org/linux-pci/alpine.DEB.2.21.2408251412590.30766@angie.orcam.me.uk
+Reported-by: Matthew W Carlis <mattc@purestorage.com>
+Link: https://lore.kernel.org/r/20240806000659.30859-1-mattc@purestorage.com/
+Link: https://lore.kernel.org/r/20240722193407.23255-1-mattc@purestorage.com/
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Cc: <stable@vger.kernel.org> # v6.5+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
+index a2ce4e08edf5..ee86793109ff 100644
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -66,7 +66,7 @@
+ * apply this erratum workaround to any downstream ports as long as they
+ * support Link Active reporting and have the Link Control 2 register.
+ * Restrict the speed to 2.5GT/s then with the Target Link Speed field,
+- * request a retrain and wait 200ms for the data link to go up.
++ * request a retrain and check the result.
+ *
+ * If this turns out successful and we know by the Vendor:Device ID it is
+ * safe to do so, then lift the restriction, letting the devices negotiate
+@@ -74,6 +74,10 @@
+ * firmware may have already arranged and lift it with ports that already
+ * report their data link being up.
+ *
++ * Otherwise revert the speed to the original setting and request a retrain
++ * again to remove any residual state, ignoring the result as it's supposed
++ * to fail anyway.
++ *
+ * Return TRUE if the link has been successfully retrained, otherwise FALSE.
+ */
+ bool pcie_failed_link_retrain(struct pci_dev *dev)
+@@ -92,6 +96,8 @@ bool pcie_failed_link_retrain(struct pci_dev *dev)
+ pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
+ if ((lnksta & (PCI_EXP_LNKSTA_LBMS | PCI_EXP_LNKSTA_DLLLA)) ==
+ PCI_EXP_LNKSTA_LBMS) {
++ u16 oldlnkctl2 = lnkctl2;
++
+ pci_info(dev, "broken device, retraining non-functional downstream link at 2.5GT/s\n");
+
+ lnkctl2 &= ~PCI_EXP_LNKCTL2_TLS;
+@@ -100,6 +106,9 @@ bool pcie_failed_link_retrain(struct pci_dev *dev)
+
+ if (pcie_retrain_link(dev, false)) {
+ pci_info(dev, "retraining failed\n");
++ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2,
++ oldlnkctl2);
++ pcie_retrain_link(dev, true);
+ return false;
+ }
+
+--
+2.46.2
+
--- /dev/null
+From 59100eb248c0b15585affa546c7f6834b30eb5a4 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Fri, 9 Aug 2024 14:25:02 +0100
+Subject: PCI: Use an error code with PCIe failed link retraining
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 59100eb248c0b15585affa546c7f6834b30eb5a4 upstream.
+
+Given how the call place in pcie_wait_for_link_delay() got structured now,
+and that pcie_retrain_link() returns a potentially useful error code,
+convert pcie_failed_link_retrain() to return an error code rather than a
+boolean status, fixing handling at the call site mentioned. Update the
+other call site accordingly.
+
+Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'")
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091156530.61955@angie.orcam.me.uk
+Reported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Cc: <stable@vger.kernel.org> # v6.5+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 2 +-
+ drivers/pci/pci.h | 6 +++---
+ drivers/pci/quirks.c | 20 ++++++++++----------
+ 3 files changed, 14 insertions(+), 14 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -1208,7 +1208,7 @@ static int pci_dev_wait(struct pci_dev *
+ if (delay > PCI_RESET_WAIT) {
+ if (retrain) {
+ retrain = false;
+- if (pcie_failed_link_retrain(bridge)) {
++ if (pcie_failed_link_retrain(bridge) == 0) {
+ delay = 1;
+ continue;
+ }
+--- a/drivers/pci/pci.h
++++ b/drivers/pci/pci.h
+@@ -530,7 +530,7 @@ void pci_acs_init(struct pci_dev *dev);
+ int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
+ int pci_dev_specific_enable_acs(struct pci_dev *dev);
+ int pci_dev_specific_disable_acs_redir(struct pci_dev *dev);
+-bool pcie_failed_link_retrain(struct pci_dev *dev);
++int pcie_failed_link_retrain(struct pci_dev *dev);
+ #else
+ static inline int pci_dev_specific_acs_enabled(struct pci_dev *dev,
+ u16 acs_flags)
+@@ -545,9 +545,9 @@ static inline int pci_dev_specific_disab
+ {
+ return -ENOTTY;
+ }
+-static inline bool pcie_failed_link_retrain(struct pci_dev *dev)
++static inline int pcie_failed_link_retrain(struct pci_dev *dev)
+ {
+- return false;
++ return -ENOTTY;
+ }
+ #endif
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -78,21 +78,21 @@
+ * again to remove any residual state, ignoring the result as it's supposed
+ * to fail anyway.
+ *
+- * Return TRUE if the link has been successfully retrained. Return FALSE
++ * Return 0 if the link has been successfully retrained. Return an error
+ * if retraining was not needed or we attempted a retrain and it failed.
+ */
+-bool pcie_failed_link_retrain(struct pci_dev *dev)
++int pcie_failed_link_retrain(struct pci_dev *dev)
+ {
+ static const struct pci_device_id ids[] = {
+ { PCI_VDEVICE(ASMEDIA, 0x2824) }, /* ASMedia ASM2824 */
+ {}
+ };
+ u16 lnksta, lnkctl2;
+- bool ret = false;
++ int ret = -ENOTTY;
+
+ if (!pci_is_pcie(dev) || !pcie_downstream_port(dev) ||
+ !pcie_cap_has_lnkctl2(dev) || !dev->link_active_reporting)
+- return false;
++ return ret;
+
+ pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &lnkctl2);
+ pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
+@@ -106,13 +106,13 @@ bool pcie_failed_link_retrain(struct pci
+ lnkctl2 |= PCI_EXP_LNKCTL2_TLS_2_5GT;
+ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2, lnkctl2);
+
+- ret = pcie_retrain_link(dev, false) == 0;
+- if (!ret) {
++ ret = pcie_retrain_link(dev, false);
++ if (ret) {
+ pci_info(dev, "retraining failed\n");
+ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2,
+ oldlnkctl2);
+ pcie_retrain_link(dev, true);
+- return false;
++ return ret;
+ }
+
+ pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &lnksta);
+@@ -129,10 +129,10 @@ bool pcie_failed_link_retrain(struct pci
+ lnkctl2 |= lnkcap & PCI_EXP_LNKCAP_SLS;
+ pcie_capability_write_word(dev, PCI_EXP_LNKCTL2, lnkctl2);
+
+- ret = pcie_retrain_link(dev, false) == 0;
+- if (!ret) {
++ ret = pcie_retrain_link(dev, false);
++ if (ret) {
+ pci_info(dev, "retraining failed\n");
+- return false;
++ return ret;
+ }
+ }
+
--- /dev/null
+From 0199d2f2bd8cd97b310f7ed82a067247d7456029 Mon Sep 17 00:00:00 2001
+From: Sean Anderson <sean.anderson@linux.dev>
+Date: Fri, 31 May 2024 12:13:32 -0400
+Subject: PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler
+
+From: Sean Anderson <sean.anderson@linux.dev>
+
+commit 0199d2f2bd8cd97b310f7ed82a067247d7456029 upstream.
+
+MSGF_LEG_MASK is laid out with INTA in bit 0, INTB in bit 1, INTC in bit 2,
+and INTD in bit 3. Hardware IRQ numbers start at 0, and we register
+PCI_NUM_INTX IRQs. So to enable INTA (aka hwirq 0) we should set bit 0.
+Remove the subtraction of one.
+
+This bug would cause INTx interrupts not to be delivered, as enabling INTB
+would actually enable INTA, and enabling INTA wouldn't enable anything at
+all. It is likely that this got overlooked for so long since most PCIe
+hardware uses MSIs. This fixes the following UBSAN error:
+
+ UBSAN: shift-out-of-bounds in ../drivers/pci/controller/pcie-xilinx-nwl.c:389:11
+ shift exponent 18446744073709551615 is too large for 32-bit type 'int'
+ CPU: 1 PID: 61 Comm: kworker/u10:1 Not tainted 6.6.20+ #268
+ Hardware name: xlnx,zynqmp (DT)
+ Workqueue: events_unbound deferred_probe_work_func
+ Call trace:
+ dump_backtrace (arch/arm64/kernel/stacktrace.c:235)
+ show_stack (arch/arm64/kernel/stacktrace.c:242)
+ dump_stack_lvl (lib/dump_stack.c:107)
+ dump_stack (lib/dump_stack.c:114)
+ __ubsan_handle_shift_out_of_bounds (lib/ubsan.c:218 lib/ubsan.c:387)
+ nwl_unmask_leg_irq (drivers/pci/controller/pcie-xilinx-nwl.c:389 (discriminator 1))
+ irq_enable (kernel/irq/internals.h:234 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)
+ __irq_startup (kernel/irq/internals.h:239 kernel/irq/chip.c:180 kernel/irq/chip.c:250)
+ irq_startup (kernel/irq/chip.c:270)
+ __setup_irq (kernel/irq/manage.c:1800)
+ request_threaded_irq (kernel/irq/manage.c:2206)
+ pcie_pme_probe (include/linux/interrupt.h:168 drivers/pci/pcie/pme.c:348)
+
+Fixes: 9a181e1093af ("PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts")
+Link: https://lore.kernel.org/r/20240531161337.864994-3-sean.anderson@linux.dev
+Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/pcie-xilinx-nwl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/controller/pcie-xilinx-nwl.c
++++ b/drivers/pci/controller/pcie-xilinx-nwl.c
+@@ -373,7 +373,7 @@ static void nwl_mask_leg_irq(struct irq_
+ u32 mask;
+ u32 val;
+
+- mask = 1 << (data->hwirq - 1);
++ mask = 1 << data->hwirq;
+ raw_spin_lock_irqsave(&pcie->leg_mask_lock, flags);
+ val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
+ nwl_bridge_writel(pcie, (val & (~mask)), MSGF_LEG_MASK);
+@@ -387,7 +387,7 @@ static void nwl_unmask_leg_irq(struct ir
+ u32 mask;
+ u32 val;
+
+- mask = 1 << (data->hwirq - 1);
++ mask = 1 << data->hwirq;
+ raw_spin_lock_irqsave(&pcie->leg_mask_lock, flags);
+ val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
+ nwl_bridge_writel(pcie, (val | mask), MSGF_LEG_MASK);
--- /dev/null
+From b722ff8ad66cf9beba971d9eb4bb7b5e6265ae5c Mon Sep 17 00:00:00 2001
+From: Wenjie Cheng <cwjhust@gmail.com>
+Date: Fri, 14 Jun 2024 00:48:41 +0000
+Subject: Revert "f2fs: use flush command instead of FUA for zoned device"
+
+From: Wenjie Cheng <cwjhust@gmail.com>
+
+commit b722ff8ad66cf9beba971d9eb4bb7b5e6265ae5c upstream.
+
+This reverts commit c550e25bca660ed2554cbb48d32b82d0bb98e4b1.
+
+Commit c550e25bca660ed2554cbb48d32b82d0bb98e4b1 ("f2fs: use flush
+command instead of FUA for zoned device") used additional flush
+command to keep write order.
+
+Since Commit dd291d77cc90eb6a86e9860ba8e6e38eebd57d12 ("block:
+Introduce zone write plugging") has enabled the block layer to
+handle this order issue, there is no need to use flush command.
+
+Signed-off-by: Wenjie Cheng <cwjhust@gmail.com>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/file.c | 3 +--
+ fs/f2fs/node.c | 2 +-
+ 2 files changed, 2 insertions(+), 3 deletions(-)
+
+--- a/fs/f2fs/file.c
++++ b/fs/f2fs/file.c
+@@ -371,8 +371,7 @@ sync_nodes:
+ f2fs_remove_ino_entry(sbi, ino, APPEND_INO);
+ clear_inode_flag(inode, FI_APPEND_WRITE);
+ flush_out:
+- if ((!atomic && F2FS_OPTION(sbi).fsync_mode != FSYNC_MODE_NOBARRIER) ||
+- (atomic && !test_opt(sbi, NOBARRIER) && f2fs_sb_has_blkzoned(sbi)))
++ if (!atomic && F2FS_OPTION(sbi).fsync_mode != FSYNC_MODE_NOBARRIER)
+ ret = f2fs_issue_flush(sbi, inode->i_ino);
+ if (!ret) {
+ f2fs_remove_ino_entry(sbi, ino, UPDATE_INO);
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -1664,7 +1664,7 @@ static int __write_node_page(struct page
+ goto redirty_out;
+ }
+
+- if (atomic && !test_opt(sbi, NOBARRIER) && !f2fs_sb_has_blkzoned(sbi))
++ if (atomic && !test_opt(sbi, NOBARRIER))
+ fio.op_flags |= REQ_PREFLUSH | REQ_FUA;
+
+ /* should add to global list before clearing PAGECACHE status */
--- /dev/null
+From e25cc4be4616fcf5689622b3226d648aab253cdb Mon Sep 17 00:00:00 2001
+From: Roman Smirnov <r.smirnov@omp.ru>
+Date: Tue, 16 Jul 2024 12:10:40 +0300
+Subject: Revert "media: tuners: fix error return code of hybrid_tuner_request_state()"
+
+From: Roman Smirnov <r.smirnov@omp.ru>
+
+commit e25cc4be4616fcf5689622b3226d648aab253cdb upstream.
+
+This reverts commit b9302fa7ed979e84b454e4ca92192cf485a4ed41.
+
+As Fedor Pchelkin pointed out, this commit violates the
+convention of using the macro return value, which causes errors.
+For example, in functions tda18271_attach(), xc5000_attach(),
+simple_tuner_attach().
+
+Link: https://lore.kernel.org/linux-media/20240424202031.syigrtrtipbq5f2l@fpc/
+Suggested-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/tuners/tuner-i2c.h | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/media/tuners/tuner-i2c.h
++++ b/drivers/media/tuners/tuner-i2c.h
+@@ -133,10 +133,8 @@ static inline int tuner_i2c_xfer_send_re
+ } \
+ if (0 == __ret) { \
+ state = kzalloc(sizeof(type), GFP_KERNEL); \
+- if (!state) { \
+- __ret = -ENOMEM; \
++ if (NULL == state) \
+ goto __fail; \
+- } \
+ state->i2c_props.addr = i2caddr; \
+ state->i2c_props.adap = i2cadap; \
+ state->i2c_props.name = devname; \
--- /dev/null
+From b17155133391d7f6dd18d3fb94a7d492fdec18fa Mon Sep 17 00:00:00 2001
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Date: Mon, 29 Jul 2024 22:52:14 +0300
+Subject: Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible"
+
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+commit b17155133391d7f6dd18d3fb94a7d492fdec18fa upstream.
+
+The rpm_requests device nodes have the compatible node. As such the
+rpmsg core uses OF modalias instead of a native rpmsg modalias. Thus if
+smd-rpm is built as a module, it doesn't get autoloaded for the device.
+
+Revert the commit bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel
+instead of compatible")
+
+Fixes: bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel instead of compatible")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Link: https://lore.kernel.org/r/20240729-fix-smd-rpm-v2-1-0776408a94c5@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/qcom/smd-rpm.c | 35 ++++++++++++++++++++++++++---------
+ 1 file changed, 26 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
+index b7056aed4c7d..9d64283d2125 100644
+--- a/drivers/soc/qcom/smd-rpm.c
++++ b/drivers/soc/qcom/smd-rpm.c
+@@ -196,9 +196,6 @@ static int qcom_smd_rpm_probe(struct rpmsg_device *rpdev)
+ {
+ struct qcom_smd_rpm *rpm;
+
+- if (!rpdev->dev.of_node)
+- return -EINVAL;
+-
+ rpm = devm_kzalloc(&rpdev->dev, sizeof(*rpm), GFP_KERNEL);
+ if (!rpm)
+ return -ENOMEM;
+@@ -218,18 +215,38 @@ static void qcom_smd_rpm_remove(struct rpmsg_device *rpdev)
+ of_platform_depopulate(&rpdev->dev);
+ }
+
+-static const struct rpmsg_device_id qcom_smd_rpm_id_table[] = {
+- { .name = "rpm_requests", },
+- { /* sentinel */ }
++static const struct of_device_id qcom_smd_rpm_of_match[] = {
++ { .compatible = "qcom,rpm-apq8084" },
++ { .compatible = "qcom,rpm-ipq6018" },
++ { .compatible = "qcom,rpm-ipq9574" },
++ { .compatible = "qcom,rpm-msm8226" },
++ { .compatible = "qcom,rpm-msm8909" },
++ { .compatible = "qcom,rpm-msm8916" },
++ { .compatible = "qcom,rpm-msm8936" },
++ { .compatible = "qcom,rpm-msm8953" },
++ { .compatible = "qcom,rpm-msm8974" },
++ { .compatible = "qcom,rpm-msm8976" },
++ { .compatible = "qcom,rpm-msm8994" },
++ { .compatible = "qcom,rpm-msm8996" },
++ { .compatible = "qcom,rpm-msm8998" },
++ { .compatible = "qcom,rpm-sdm660" },
++ { .compatible = "qcom,rpm-sm6115" },
++ { .compatible = "qcom,rpm-sm6125" },
++ { .compatible = "qcom,rpm-sm6375" },
++ { .compatible = "qcom,rpm-qcm2290" },
++ { .compatible = "qcom,rpm-qcs404" },
++ {}
+ };
+-MODULE_DEVICE_TABLE(rpmsg, qcom_smd_rpm_id_table);
++MODULE_DEVICE_TABLE(of, qcom_smd_rpm_of_match);
+
+ static struct rpmsg_driver qcom_smd_rpm_driver = {
+ .probe = qcom_smd_rpm_probe,
+ .remove = qcom_smd_rpm_remove,
+ .callback = qcom_smd_rpm_callback,
+- .id_table = qcom_smd_rpm_id_table,
+- .drv.name = "qcom_smd_rpm",
++ .drv = {
++ .name = "qcom_smd_rpm",
++ .of_match_table = qcom_smd_rpm_of_match,
++ },
+ };
+
+ static int __init qcom_smd_rpm_init(void)
+--
+2.46.2
+
io_uring-sqpoll-retain-test-for-whether-the-cpu-is-valid.patch
io_uring-sqpoll-do-not-put-cpumask-on-stack.patch
remove-.orig-pattern-from-.gitignore.patch
+pci-revert-to-the-original-speed-after-pcie-failed-link-retraining.patch
+pci-clear-the-lbms-bit-after-a-link-retrain.patch
+pci-dra7xx-fix-threaded-irq-request-for-dra7xx-pcie-main-irq.patch
+pci-imx6-fix-missing-call-to-phy_power_off-in-error-handling.patch
+pci-correct-error-reporting-with-pcie-failed-link-retraining.patch
+pci-use-an-error-code-with-pcie-failed-link-retraining.patch
+pci-xilinx-nwl-fix-off-by-one-in-intx-irq-handler.patch
+revert-soc-qcom-smd-rpm-match-rpmsg-channel-instead-of-compatible.patch
+asoc-rt5682-return-devm_of_clk_add_hw_provider-to-transfer-the-error.patch
+soc-fsl-cpm1-tsa-fix-tsa_write8.patch
+soc-versatile-integrator-fix-of-node-leak-in-probe-error-path.patch
+revert-f2fs-use-flush-command-instead-of-fua-for-zoned-device.patch
+revert-media-tuners-fix-error-return-code-of-hybrid_tuner_request_state.patch
+iommufd-protect-against-overflow-of-align-during-iova-allocation.patch
+input-adp5588-keys-fix-check-on-return-code.patch
+input-i8042-add-tuxedo-stellaris-16-gen5-amd-to-i8042-quirk-table.patch
+input-i8042-add-tuxedo-stellaris-15-slim-gen6-amd-to-i8042-quirk-table.patch
+input-i8042-add-another-board-name-for-tuxedo-stellaris-gen5-amd-line.patch
+kvm-arm64-add-memory-length-checks-and-remove-inline-in-do_ffa_mem_xfer.patch
+kvm-x86-enforce-x2apic-s-must-be-zero-reserved-icr-bits.patch
+kvm-x86-move-x2apic-icr-helper-above-kvm_apic_write_nodecode.patch
+kvm-use-dedicated-mutex-to-protect-kvm_usage_count-to-avoid-deadlock.patch
+drm-amd-display-skip-recompute-dsc-params-if-no-stream-on-link.patch
+drm-amd-display-add-hdmi-dsc-native-ycbcr422-support.patch
--- /dev/null
+From 47a347bae9a491b467ab3543e4725a3e4fbe30f5 Mon Sep 17 00:00:00 2001
+From: Herve Codina <herve.codina@bootlin.com>
+Date: Thu, 8 Aug 2024 09:10:56 +0200
+Subject: soc: fsl: cpm1: tsa: Fix tsa_write8()
+
+From: Herve Codina <herve.codina@bootlin.com>
+
+commit 47a347bae9a491b467ab3543e4725a3e4fbe30f5 upstream.
+
+The tsa_write8() parameter is an u32 value. This is not consistent with
+the function itself. Indeed, tsa_write8() writes an 8bits value.
+
+Be consistent and use an u8 parameter value.
+
+Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA")
+Cc: stable@vger.kernel.org
+Signed-off-by: Herve Codina <herve.codina@bootlin.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Link: https://lore.kernel.org/r/20240808071132.149251-4-herve.codina@bootlin.com
+Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/fsl/qe/tsa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/soc/fsl/qe/tsa.c b/drivers/soc/fsl/qe/tsa.c
+index 6c5741cf5e9d..53968ea84c88 100644
+--- a/drivers/soc/fsl/qe/tsa.c
++++ b/drivers/soc/fsl/qe/tsa.c
+@@ -140,7 +140,7 @@ static inline void tsa_write32(void __iomem *addr, u32 val)
+ iowrite32be(val, addr);
+ }
+
+-static inline void tsa_write8(void __iomem *addr, u32 val)
++static inline void tsa_write8(void __iomem *addr, u8 val)
+ {
+ iowrite8(val, addr);
+ }
+--
+2.46.2
+
--- /dev/null
+From 874c5b601856adbfda10846b9770a6c66c41e229 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Sun, 25 Aug 2024 20:05:22 +0200
+Subject: soc: versatile: integrator: fix OF node leak in probe() error path
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 874c5b601856adbfda10846b9770a6c66c41e229 upstream.
+
+Driver is leaking OF node reference obtained from
+of_find_matching_node().
+
+Fixes: f956a785a282 ("soc: move SoC driver for the ARM Integrator")
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/20240825-soc-dev-fixes-v1-1-ff4b35abed83@linaro.org
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/versatile/soc-integrator.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/soc/versatile/soc-integrator.c
++++ b/drivers/soc/versatile/soc-integrator.c
+@@ -113,6 +113,7 @@ static int __init integrator_soc_init(vo
+ return -ENODEV;
+
+ syscon_regmap = syscon_node_to_regmap(np);
++ of_node_put(np);
+ if (IS_ERR(syscon_regmap))
+ return PTR_ERR(syscon_regmap);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
