From: Greg Kroah-Hartman Date: Mon, 12 May 2025 10:13:08 +0000 (+0200) Subject: 6.14-stable patches X-Git-Tag: v5.15.183~52 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c7f4e1508866c64c7806e72a5635af3f034aa508;p=thirdparty%2Fkernel%2Fstable-queue.git 6.14-stable patches added patches: drm-amd-display-copy-aux-read-reply-data-whenever-length-0.patch drm-amd-display-fix-invalid-context-error-in-dml-helper.patch drm-amd-display-fix-the-checking-condition-in-dmub-aux-handling.patch drm-amd-display-fix-wrong-handling-for-aux_defer-case.patch drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch drm-amd-display-remove-incorrect-checking-in-dmub-aux-handler.patch drm-amdgpu-fix-pm-notifier-handling.patch drm-amdgpu-hdp4-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch drm-xe-add-page-queue-multiplier.patch iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch iio-adc-ad7606-fix-serial-register-access.patch iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch iio-adc-rockchip-fix-clock-initialization-sequence.patch iio-adis16201-correct-inclinometer-channel-resolution.patch iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch iio-chemical-sps30-use-aligned_s64-for-timestamp.patch iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch iio-hid-sensor-prox-restore-lost-scale-assignments.patch iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch usb-uhci-platform-make-the-clock-really-optional.patch xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch --- diff --git a/queue-6.14/drm-amd-display-copy-aux-read-reply-data-whenever-length-0.patch b/queue-6.14/drm-amd-display-copy-aux-read-reply-data-whenever-length-0.patch new file mode 100644 index 0000000000..6d6d1397a1 --- /dev/null +++ b/queue-6.14/drm-amd-display-copy-aux-read-reply-data-whenever-length-0.patch @@ -0,0 +1,43 @@ +From 3924f45d4de7250a603fd7b50379237a6a0e5adf Mon Sep 17 00:00:00 2001 +From: Wayne Lin +Date: Sun, 20 Apr 2025 17:50:03 +0800 +Subject: drm/amd/display: Copy AUX read reply data whenever length > 0 + +From: Wayne Lin + +commit 3924f45d4de7250a603fd7b50379237a6a0e5adf upstream. + +[Why] +amdgpu_dm_process_dmub_aux_transfer_sync() should return all exact data +reply from the sink side. Don't do the analysis job in it. + +[How] +Remove unnecessary check condition AUX_TRANSACTION_REPLY_AUX_ACK. + +Fixes: ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer") +Cc: Mario Limonciello +Cc: Alex Deucher +Reviewed-by: Ray Wu +Signed-off-by: Wayne Lin +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit 9b540e3fe6796fec4fb1344f3be8952fc2f084d4) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -12621,8 +12621,7 @@ int amdgpu_dm_process_dmub_aux_transfer_ + /* The reply is stored in the top nibble of the command. */ + payload->reply[0] = (adev->dm.dmub_notify->aux_reply.command >> 4) & 0xF; + +- if (!payload->write && p_notify->aux_reply.length && +- (payload->reply[0] == AUX_TRANSACTION_REPLY_AUX_ACK)) ++ if (!payload->write && p_notify->aux_reply.length) + memcpy(payload->data, p_notify->aux_reply.data, + p_notify->aux_reply.length); + diff --git a/queue-6.14/drm-amd-display-fix-invalid-context-error-in-dml-helper.patch b/queue-6.14/drm-amd-display-fix-invalid-context-error-in-dml-helper.patch new file mode 100644 index 0000000000..48f44ca525 --- /dev/null +++ b/queue-6.14/drm-amd-display-fix-invalid-context-error-in-dml-helper.patch @@ -0,0 +1,82 @@ +From 9984db63742099ee3f3cff35cf71306d10e64356 Mon Sep 17 00:00:00 2001 +From: Roman Li +Date: Mon, 14 Apr 2025 12:56:48 -0400 +Subject: drm/amd/display: Fix invalid context error in dml helper + +From: Roman Li + +commit 9984db63742099ee3f3cff35cf71306d10e64356 upstream. + +[Why] +"BUG: sleeping function called from invalid context" error. +after: +"drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()" + +The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag +for memory allocation, which shouldn't be used in atomic contexts. + +The allocation is needed only for using another helper function +get_scaler_data_for_plane(). + +[How] +Modify helpers to pass a pointer to scaler_data within existing context, +eliminating the need for dynamic memory allocation/deallocation +and copying. + +Fixes: 366e77cd4923 ("drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()") +Reviewed-by: Aurabindo Pillai +Signed-off-by: Roman Li +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c | 14 +++------- + 1 file changed, 5 insertions(+), 9 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c ++++ b/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c +@@ -969,7 +969,9 @@ static void populate_dml_surface_cfg_fro + } + } + +-static void get_scaler_data_for_plane(const struct dc_plane_state *in, struct dc_state *context, struct scaler_data *out) ++static struct scaler_data *get_scaler_data_for_plane( ++ const struct dc_plane_state *in, ++ struct dc_state *context) + { + int i; + struct pipe_ctx *temp_pipe = &context->res_ctx.temp_pipe; +@@ -990,7 +992,7 @@ static void get_scaler_data_for_plane(co + } + + ASSERT(i < MAX_PIPES); +- memcpy(out, &temp_pipe->plane_res.scl_data, sizeof(*out)); ++ return &temp_pipe->plane_res.scl_data; + } + + static void populate_dummy_dml_plane_cfg(struct dml_plane_cfg_st *out, unsigned int location, +@@ -1053,11 +1055,7 @@ static void populate_dml_plane_cfg_from_ + const struct dc_plane_state *in, struct dc_state *context, + const struct soc_bounding_box_st *soc) + { +- struct scaler_data *scaler_data = kzalloc(sizeof(*scaler_data), GFP_KERNEL); +- if (!scaler_data) +- return; +- +- get_scaler_data_for_plane(in, context, scaler_data); ++ struct scaler_data *scaler_data = get_scaler_data_for_plane(in, context); + + out->CursorBPP[location] = dml_cur_32bit; + out->CursorWidth[location] = 256; +@@ -1122,8 +1120,6 @@ static void populate_dml_plane_cfg_from_ + out->DynamicMetadataTransmittedBytes[location] = 0; + + out->NumberOfCursors[location] = 1; +- +- kfree(scaler_data); + } + + static unsigned int map_stream_to_dml_display_cfg(const struct dml2_context *dml2, diff --git a/queue-6.14/drm-amd-display-fix-the-checking-condition-in-dmub-aux-handling.patch b/queue-6.14/drm-amd-display-fix-the-checking-condition-in-dmub-aux-handling.patch new file mode 100644 index 0000000000..5d57140f08 --- /dev/null +++ b/queue-6.14/drm-amd-display-fix-the-checking-condition-in-dmub-aux-handling.patch @@ -0,0 +1,36 @@ +From bc70e11b550d37fbd9eaed0f113ba560894f1609 Mon Sep 17 00:00:00 2001 +From: Wayne Lin +Date: Sun, 20 Apr 2025 16:29:07 +0800 +Subject: drm/amd/display: Fix the checking condition in dmub aux handling + +From: Wayne Lin + +commit bc70e11b550d37fbd9eaed0f113ba560894f1609 upstream. + +[Why & How] +Fix the checking condition for detecting AUX_RET_ERROR_PROTOCOL_ERROR. +It was wrongly checking by "not equals to" + +Reviewed-by: Ray Wu +Signed-off-by: Wayne Lin +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit 1db6c9e9b62e1a8912f0a281c941099fca678da3) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -12607,7 +12607,7 @@ int amdgpu_dm_process_dmub_aux_transfer_ + * Transient states before tunneling is enabled could + * lead to this error. We can ignore this for now. + */ +- if (p_notify->result != AUX_RET_ERROR_PROTOCOL_ERROR) { ++ if (p_notify->result == AUX_RET_ERROR_PROTOCOL_ERROR) { + DRM_WARN("DPIA AUX failed on 0x%x(%d), error %d\n", + payload->address, payload->length, + p_notify->result); diff --git a/queue-6.14/drm-amd-display-fix-wrong-handling-for-aux_defer-case.patch b/queue-6.14/drm-amd-display-fix-wrong-handling-for-aux_defer-case.patch new file mode 100644 index 0000000000..a0d5f88413 --- /dev/null +++ b/queue-6.14/drm-amd-display-fix-wrong-handling-for-aux_defer-case.patch @@ -0,0 +1,90 @@ +From 65924ec69b29296845c7f628112353438e63ea56 Mon Sep 17 00:00:00 2001 +From: Wayne Lin +Date: Sun, 20 Apr 2025 19:22:14 +0800 +Subject: drm/amd/display: Fix wrong handling for AUX_DEFER case + +From: Wayne Lin + +commit 65924ec69b29296845c7f628112353438e63ea56 upstream. + +[Why] +We incorrectly ack all bytes get written when the reply actually is defer. +When it's defer, means sink is not ready for the request. We should +retry the request. + +[How] +Only reply all data get written when receive I2C_ACK|AUX_ACK. Otherwise, +reply the number of actual written bytes received from the sink. +Add some messages to facilitate debugging as well. + +Fixes: ad6756b4d773 ("drm/amd/display: Shift dc link aux to aux_payload") +Cc: Mario Limonciello +Cc: Alex Deucher +Reviewed-by: Ray Wu +Signed-off-by: Wayne Lin +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit 3637e457eb0000bc37d8bbbec95964aad2fb29fd) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 ++++++++++-- + 1 file changed, 24 insertions(+), 4 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 +@@ -51,6 +51,9 @@ + + #define PEAK_FACTOR_X1000 1006 + ++/* ++ * This function handles both native AUX and I2C-Over-AUX transactions. ++ */ + static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, + struct drm_dp_aux_msg *msg) + { +@@ -87,15 +90,25 @@ static ssize_t dm_dp_aux_transfer(struct + if (adev->dm.aux_hpd_discon_quirk) { + if (msg->address == DP_SIDEBAND_MSG_DOWN_REQ_BASE && + operation_result == AUX_RET_ERROR_HPD_DISCON) { +- result = 0; ++ result = msg->size; + operation_result = AUX_RET_SUCCESS; + } + } + +- if (payload.write && result >= 0) +- result = msg->size; ++ /* ++ * result equals to 0 includes the cases of AUX_DEFER/I2C_DEFER ++ */ ++ if (payload.write && result >= 0) { ++ if (result) { ++ /*one byte indicating partially written bytes. Force 0 to retry*/ ++ drm_info(adev_to_drm(adev), "amdgpu: AUX partially written\n"); ++ result = 0; ++ } else if (!payload.reply[0]) ++ /*I2C_ACK|AUX_ACK*/ ++ result = msg->size; ++ } + +- if (result < 0) ++ if (result < 0) { + switch (operation_result) { + case AUX_RET_SUCCESS: + break; +@@ -114,6 +127,13 @@ static ssize_t dm_dp_aux_transfer(struct + break; + } + ++ drm_info(adev_to_drm(adev), "amdgpu: DP AUX transfer fail:%d\n", operation_result); ++ } ++ ++ if (payload.reply[0]) ++ drm_info(adev_to_drm(adev), "amdgpu: AUX reply command not ACK: 0x%02x.", ++ payload.reply[0]); ++ + return result; + } + diff --git a/queue-6.14/drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch b/queue-6.14/drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch new file mode 100644 index 0000000000..d565110e34 --- /dev/null +++ b/queue-6.14/drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch @@ -0,0 +1,60 @@ +From f1c6be3999d2be2673a51a9be0caf9348e254e52 Mon Sep 17 00:00:00 2001 +From: Aurabindo Pillai +Date: Wed, 16 Apr 2025 11:26:54 -0400 +Subject: drm/amd/display: more liberal vmin/vmax update for freesync + +From: Aurabindo Pillai + +commit f1c6be3999d2be2673a51a9be0caf9348e254e52 upstream. + +[Why] +FAMS2 expects vmin/vmax to be updated in the case when freesync is +off, but supported. But we only update it when freesync is enabled. + +[How] +Change the vsync handler such that dc_stream_adjust_vmin_vmax() its called +irrespective of whether freesync is enabled. If freesync is supported, +then there is no harm in updating vmin/vmax registers. + +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3546 +Reviewed-by: ChiaHsuan Chung +Signed-off-by: Aurabindo Pillai +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 +++++++++++----- + 1 file changed, 11 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 +@@ -668,15 +668,21 @@ static void dm_crtc_high_irq(void *inter + spin_lock_irqsave(&adev_to_drm(adev)->event_lock, flags); + + if (acrtc->dm_irq_params.stream && +- acrtc->dm_irq_params.vrr_params.supported && +- acrtc->dm_irq_params.freesync_config.state == +- VRR_STATE_ACTIVE_VARIABLE) { ++ acrtc->dm_irq_params.vrr_params.supported) { ++ bool replay_en = acrtc->dm_irq_params.stream->link->replay_settings.replay_feature_enabled; ++ bool psr_en = acrtc->dm_irq_params.stream->link->psr_settings.psr_feature_enabled; ++ bool fs_active_var_en = acrtc->dm_irq_params.freesync_config.state == VRR_STATE_ACTIVE_VARIABLE; ++ + mod_freesync_handle_v_update(adev->dm.freesync_module, + acrtc->dm_irq_params.stream, + &acrtc->dm_irq_params.vrr_params); + +- dc_stream_adjust_vmin_vmax(adev->dm.dc, acrtc->dm_irq_params.stream, +- &acrtc->dm_irq_params.vrr_params.adjust); ++ /* update vmin_vmax only if freesync is enabled, or only if PSR and REPLAY are disabled */ ++ if (fs_active_var_en || (!fs_active_var_en && !replay_en && !psr_en)) { ++ dc_stream_adjust_vmin_vmax(adev->dm.dc, ++ acrtc->dm_irq_params.stream, ++ &acrtc->dm_irq_params.vrr_params.adjust); ++ } + } + + /* diff --git a/queue-6.14/drm-amd-display-remove-incorrect-checking-in-dmub-aux-handler.patch b/queue-6.14/drm-amd-display-remove-incorrect-checking-in-dmub-aux-handler.patch new file mode 100644 index 0000000000..f065eb95dc --- /dev/null +++ b/queue-6.14/drm-amd-display-remove-incorrect-checking-in-dmub-aux-handler.patch @@ -0,0 +1,53 @@ +From 396dc51b3b7ea524bf8061f478332d0039e96d5d Mon Sep 17 00:00:00 2001 +From: Wayne Lin +Date: Sun, 20 Apr 2025 16:56:54 +0800 +Subject: drm/amd/display: Remove incorrect checking in dmub aux handler + +From: Wayne Lin + +commit 396dc51b3b7ea524bf8061f478332d0039e96d5d upstream. + +[Why & How] +"Request length != reply length" is expected behavior defined in spec. +It's not an invalid reply. Besides, replied data handling logic is not +designed to be written in amdgpu_dm_process_dmub_aux_transfer_sync(). +Remove the incorrectly handling section. + +Fixes: ead08b95fa50 ("drm/amd/display: Fix race condition in DPIA AUX transfer") +Cc: Mario Limonciello +Cc: Alex Deucher +Reviewed-by: Ray Wu +Signed-off-by: Wayne Lin +Signed-off-by: Ray Wu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit 81b5c6fa62af62fe89ae9576f41aae37830b94cb) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +----------- + 1 file changed, 1 insertion(+), 11 deletions(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -12622,19 +12622,9 @@ int amdgpu_dm_process_dmub_aux_transfer_ + payload->reply[0] = (adev->dm.dmub_notify->aux_reply.command >> 4) & 0xF; + + if (!payload->write && p_notify->aux_reply.length && +- (payload->reply[0] == AUX_TRANSACTION_REPLY_AUX_ACK)) { +- +- if (payload->length != p_notify->aux_reply.length) { +- DRM_WARN("invalid read length %d from DPIA AUX 0x%x(%d)!\n", +- p_notify->aux_reply.length, +- payload->address, payload->length); +- *operation_result = AUX_RET_ERROR_INVALID_REPLY; +- goto out; +- } +- ++ (payload->reply[0] == AUX_TRANSACTION_REPLY_AUX_ACK)) + memcpy(payload->data, p_notify->aux_reply.data, + p_notify->aux_reply.length); +- } + + /* success */ + ret = p_notify->aux_reply.length; diff --git a/queue-6.14/drm-amdgpu-fix-pm-notifier-handling.patch b/queue-6.14/drm-amdgpu-fix-pm-notifier-handling.patch new file mode 100644 index 0000000000..d144cc2a87 --- /dev/null +++ b/queue-6.14/drm-amdgpu-fix-pm-notifier-handling.patch @@ -0,0 +1,94 @@ +From 4aaffc85751da5722e858e4333e8cf0aa4b6c78f Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Thu, 1 May 2025 13:46:46 -0400 +Subject: drm/amdgpu: fix pm notifier handling + +From: Alex Deucher + +commit 4aaffc85751da5722e858e4333e8cf0aa4b6c78f upstream. + +Set the s3/s0ix and s4 flags in the pm notifier so that we can skip +the resource evictions properly in pm prepare based on whether +we are suspending or hibernating. Drop the eviction as processes +are not frozen at this time, we we can end up getting stuck trying +to evict VRAM while applications continue to submit work which +causes the buffers to get pulled back into VRAM. + +v2: Move suspend flags out of pm notifier (Mario) + +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4178 +Fixes: 2965e6355dcd ("drm/amd: Add Suspend/Hibernate notification callback support") +Cc: Mario Limonciello +Reviewed-by: Mario Limonciello +Signed-off-by: Alex Deucher +(cherry picked from commit 06f2dcc241e7e5c681f81fbc46cacdf4bfd7d6d7) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 +++++------------- + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 10 +--------- + 2 files changed, 6 insertions(+), 22 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +@@ -4819,28 +4819,20 @@ static int amdgpu_device_evict_resources + * @data: data + * + * This function is called when the system is about to suspend or hibernate. +- * It is used to evict resources from the device before the system goes to +- * sleep while there is still access to swap. ++ * It is used to set the appropriate flags so that eviction can be optimized ++ * in the pm prepare callback. + */ + static int amdgpu_device_pm_notifier(struct notifier_block *nb, unsigned long mode, + void *data) + { + struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, pm_nb); +- int r; + + switch (mode) { + case PM_HIBERNATION_PREPARE: + adev->in_s4 = true; +- fallthrough; +- case PM_SUSPEND_PREPARE: +- r = amdgpu_device_evict_resources(adev); +- /* +- * This is considered non-fatal at this time because +- * amdgpu_device_prepare() will also fatally evict resources. +- * See https://gitlab.freedesktop.org/drm/amd/-/issues/3781 +- */ +- if (r) +- drm_warn(adev_to_drm(adev), "Failed to evict resources, freeze active processes if problems occur: %d\n", r); ++ break; ++ case PM_POST_HIBERNATION: ++ adev->in_s4 = false; + break; + } + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +@@ -2582,13 +2582,8 @@ static int amdgpu_pmops_freeze(struct de + static int amdgpu_pmops_thaw(struct device *dev) + { + struct drm_device *drm_dev = dev_get_drvdata(dev); +- struct amdgpu_device *adev = drm_to_adev(drm_dev); +- int r; + +- r = amdgpu_device_resume(drm_dev, true); +- adev->in_s4 = false; +- +- return r; ++ return amdgpu_device_resume(drm_dev, true); + } + + static int amdgpu_pmops_poweroff(struct device *dev) +@@ -2601,9 +2596,6 @@ static int amdgpu_pmops_poweroff(struct + static int amdgpu_pmops_restore(struct device *dev) + { + struct drm_device *drm_dev = dev_get_drvdata(dev); +- struct amdgpu_device *adev = drm_to_adev(drm_dev); +- +- adev->in_s4 = false; + + return amdgpu_device_resume(drm_dev, true); + } diff --git a/queue-6.14/drm-amdgpu-hdp4-use-memcfg-register-to-post-the-write-for-hdp-flush.patch b/queue-6.14/drm-amdgpu-hdp4-use-memcfg-register-to-post-the-write-for-hdp-flush.patch new file mode 100644 index 0000000000..976f50d9c4 --- /dev/null +++ b/queue-6.14/drm-amdgpu-hdp4-use-memcfg-register-to-post-the-write-for-hdp-flush.patch @@ -0,0 +1,43 @@ +From f690e3974755a650259a45d71456decc9c96a282 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 30 Apr 2025 12:45:04 -0400 +Subject: drm/amdgpu/hdp4: use memcfg register to post the write for HDP flush + +From: Alex Deucher + +commit f690e3974755a650259a45d71456decc9c96a282 upstream. + +Reading back the remapped HDP flush register seems to cause +problems on some platforms. All we need is a read, so read back +the memcfg register. + +Fixes: c9b8dcabb52a ("drm/amdgpu/hdp4.0: do a posting read when flushing HDP") +Reported-by: Alexey Klimov +Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit 5c937b4a6050316af37ef214825b6340b5e9e391) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/hdp_v4_0.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/hdp_v4_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/hdp_v4_0.c +@@ -42,7 +42,12 @@ static void hdp_v4_0_flush_hdp(struct am + { + if (!ring || !ring->funcs->emit_wreg) { + WREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); +- RREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2); ++ /* We just need to read back a register to post the write. ++ * Reading back the remapped register causes problems on ++ * some platforms so just read back the memory size register. ++ */ ++ if (adev->nbio.funcs->get_memsize) ++ adev->nbio.funcs->get_memsize(adev); + } else { + amdgpu_ring_emit_wreg(ring, (adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); + } diff --git a/queue-6.14/drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch b/queue-6.14/drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch new file mode 100644 index 0000000000..d3fc0e7ac5 --- /dev/null +++ b/queue-6.14/drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch @@ -0,0 +1,43 @@ +From 0e33e0f339b91eecd9558311449a3d1e728722d4 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 30 Apr 2025 12:46:56 -0400 +Subject: drm/amdgpu/hdp5: use memcfg register to post the write for HDP flush + +From: Alex Deucher + +commit 0e33e0f339b91eecd9558311449a3d1e728722d4 upstream. + +Reading back the remapped HDP flush register seems to cause +problems on some platforms. All we need is a read, so read back +the memcfg register. + +Fixes: cf424020e040 ("drm/amdgpu/hdp5.0: do a posting read when flushing HDP") +Reported-by: Alexey Klimov +Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit a5cb344033c7598762e89255e8ff52827abb57a4) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/hdp_v5_0.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/hdp_v5_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/hdp_v5_0.c +@@ -33,7 +33,12 @@ static void hdp_v5_0_flush_hdp(struct am + { + if (!ring || !ring->funcs->emit_wreg) { + WREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); +- RREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2); ++ /* We just need to read back a register to post the write. ++ * Reading back the remapped register causes problems on ++ * some platforms so just read back the memory size register. ++ */ ++ if (adev->nbio.funcs->get_memsize) ++ adev->nbio.funcs->get_memsize(adev); + } else { + amdgpu_ring_emit_wreg(ring, (adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); + } diff --git a/queue-6.14/drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch b/queue-6.14/drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch new file mode 100644 index 0000000000..f0c587438f --- /dev/null +++ b/queue-6.14/drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch @@ -0,0 +1,48 @@ +From dbc988c689333faeeed44d5561f372ff20395304 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 30 Apr 2025 12:47:37 -0400 +Subject: drm/amdgpu/hdp5.2: use memcfg register to post the write for HDP flush + +From: Alex Deucher + +commit dbc988c689333faeeed44d5561f372ff20395304 upstream. + +Reading back the remapped HDP flush register seems to cause +problems on some platforms. All we need is a read, so read back +the memcfg register. + +Fixes: f756dbac1ce1 ("drm/amdgpu/hdp5.2: do a posting read when flushing HDP") +Reported-by: Alexey Klimov +Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit 4a89b7698e771914b4d5b571600c76e2fdcbe2a9) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/hdp_v5_2.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/hdp_v5_2.c ++++ b/drivers/gpu/drm/amd/amdgpu/hdp_v5_2.c +@@ -34,7 +34,17 @@ static void hdp_v5_2_flush_hdp(struct am + if (!ring || !ring->funcs->emit_wreg) { + WREG32_NO_KIQ((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, + 0); +- RREG32_NO_KIQ((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2); ++ if (amdgpu_sriov_vf(adev)) { ++ /* this is fine because SR_IOV doesn't remap the register */ ++ RREG32_NO_KIQ((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2); ++ } else { ++ /* We just need to read back a register to post the write. ++ * Reading back the remapped register causes problems on ++ * some platforms so just read back the memory size register. ++ */ ++ if (adev->nbio.funcs->get_memsize) ++ adev->nbio.funcs->get_memsize(adev); ++ } + } else { + amdgpu_ring_emit_wreg(ring, + (adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, diff --git a/queue-6.14/drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch b/queue-6.14/drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch new file mode 100644 index 0000000000..c95af96430 --- /dev/null +++ b/queue-6.14/drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch @@ -0,0 +1,43 @@ +From ca28e80abe4219c8f1a2961ae05102d70af6dc87 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 30 Apr 2025 12:48:51 -0400 +Subject: drm/amdgpu/hdp6: use memcfg register to post the write for HDP flush + +From: Alex Deucher + +commit ca28e80abe4219c8f1a2961ae05102d70af6dc87 upstream. + +Reading back the remapped HDP flush register seems to cause +problems on some platforms. All we need is a read, so read back +the memcfg register. + +Fixes: abe1cbaec6cf ("drm/amdgpu/hdp6.0: do a posting read when flushing HDP") +Reported-by: Alexey Klimov +Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit 84141ff615951359c9a99696fd79a36c465ed847) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/hdp_v6_0.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/hdp_v6_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/hdp_v6_0.c +@@ -36,7 +36,12 @@ static void hdp_v6_0_flush_hdp(struct am + { + if (!ring || !ring->funcs->emit_wreg) { + WREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); +- RREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2); ++ /* We just need to read back a register to post the write. ++ * Reading back the remapped register causes problems on ++ * some platforms so just read back the memory size register. ++ */ ++ if (adev->nbio.funcs->get_memsize) ++ adev->nbio.funcs->get_memsize(adev); + } else { + amdgpu_ring_emit_wreg(ring, (adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); + } diff --git a/queue-6.14/drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch b/queue-6.14/drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch new file mode 100644 index 0000000000..4ae9503d49 --- /dev/null +++ b/queue-6.14/drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch @@ -0,0 +1,43 @@ +From 5a11a2767731139bf87e667331aa2209e33a1d19 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 30 Apr 2025 12:50:02 -0400 +Subject: drm/amdgpu/hdp7: use memcfg register to post the write for HDP flush + +From: Alex Deucher + +commit 5a11a2767731139bf87e667331aa2209e33a1d19 upstream. + +Reading back the remapped HDP flush register seems to cause +problems on some platforms. All we need is a read, so read back +the memcfg register. + +Fixes: 689275140cb8 ("drm/amdgpu/hdp7.0: do a posting read when flushing HDP") +Reported-by: Alexey Klimov +Link: https://lists.freedesktop.org/archives/amd-gfx/2025-April/123150.html +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4119 +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3908 +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit dbc064adfcf9095e7d895bea87b2f75c1ab23236) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/hdp_v7_0.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/hdp_v7_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/hdp_v7_0.c +@@ -33,7 +33,12 @@ static void hdp_v7_0_flush_hdp(struct am + { + if (!ring || !ring->funcs->emit_wreg) { + WREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); +- RREG32((adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2); ++ /* We just need to read back a register to post the write. ++ * Reading back the remapped register causes problems on ++ * some platforms so just read back the memory size register. ++ */ ++ if (adev->nbio.funcs->get_memsize) ++ adev->nbio.funcs->get_memsize(adev); + } else { + amdgpu_ring_emit_wreg(ring, (adev->rmmio_remap.reg_offset + KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0); + } diff --git a/queue-6.14/drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch b/queue-6.14/drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch new file mode 100644 index 0000000000..8d0d4b66a8 --- /dev/null +++ b/queue-6.14/drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch @@ -0,0 +1,129 @@ +From b7e84fb708392b37e5dbb2a95db9b94a0e3f0aa2 Mon Sep 17 00:00:00 2001 +From: Ruijing Dong +Date: Fri, 2 May 2025 11:19:26 -0400 +Subject: drm/amdgpu/vcn: using separate VCN1_AON_SOC offset + +From: Ruijing Dong + +commit b7e84fb708392b37e5dbb2a95db9b94a0e3f0aa2 upstream. + +VCN1_AON_SOC_ADDRESS_3_0 offset varies on different +VCN generations, the issue in vcn4.0.5 is caused by +a different VCN1_AON_SOC_ADDRESS_3_0 offset. + +This patch does the following: + + 1. use the same offset for other VCN generations. + 2. use the vcn4.0.5 special offset + 3. update vcn_4_0 and vcn_5_0 + +Acked-by: Saleemkhan Jamadar +Reviewed-by: Leo Liu +Signed-off-by: Ruijing Dong +Signed-off-by: Alex Deucher +(cherry picked from commit 5c89ceda9984498b28716944633a9a01cbb2c90d) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 - + drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 1 + + drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 1 + + drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 1 + + drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4 +++- + drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 1 + + drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c | 1 + + drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c | 3 ++- + 8 files changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h +@@ -66,7 +66,6 @@ + #define VCN_ENC_CMD_REG_WAIT 0x0000000c + + #define VCN_AON_SOC_ADDRESS_2_0 0x1f800 +-#define VCN1_AON_SOC_ADDRESS_3_0 0x48000 + #define VCN_VID_IP_ADDRESS_2_0 0x0 + #define VCN_AON_IP_ADDRESS_2_0 0x30000 + +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c +@@ -39,6 +39,7 @@ + + #define VCN_VID_SOC_ADDRESS_2_0 0x1fa00 + #define VCN1_VID_SOC_ADDRESS_3_0 0x48200 ++#define VCN1_AON_SOC_ADDRESS_3_0 0x48000 + + #define mmUVD_CONTEXT_ID_INTERNAL_OFFSET 0x1fd + #define mmUVD_GPCOM_VCPU_CMD_INTERNAL_OFFSET 0x503 +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c +@@ -39,6 +39,7 @@ + + #define VCN_VID_SOC_ADDRESS_2_0 0x1fa00 + #define VCN1_VID_SOC_ADDRESS_3_0 0x48200 ++#define VCN1_AON_SOC_ADDRESS_3_0 0x48000 + + #define mmUVD_CONTEXT_ID_INTERNAL_OFFSET 0x27 + #define mmUVD_GPCOM_VCPU_CMD_INTERNAL_OFFSET 0x0f +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c +@@ -40,6 +40,7 @@ + + #define VCN_VID_SOC_ADDRESS_2_0 0x1fa00 + #define VCN1_VID_SOC_ADDRESS_3_0 0x48200 ++#define VCN1_AON_SOC_ADDRESS_3_0 0x48000 + + #define mmUVD_CONTEXT_ID_INTERNAL_OFFSET 0x27 + #define mmUVD_GPCOM_VCPU_CMD_INTERNAL_OFFSET 0x0f +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c +@@ -46,6 +46,7 @@ + + #define VCN_VID_SOC_ADDRESS_2_0 0x1fb00 + #define VCN1_VID_SOC_ADDRESS_3_0 0x48300 ++#define VCN1_AON_SOC_ADDRESS_3_0 0x48000 + + #define VCN_HARVEST_MMSCH 0 + +@@ -582,7 +583,8 @@ static void vcn_v4_0_mc_resume_dpg_mode( + + /* VCN global tiling registers */ + WREG32_SOC15_DPG_MODE(inst_idx, SOC15_DPG_MODE_OFFSET( +- VCN, 0, regUVD_GFX10_ADDR_CONFIG), adev->gfx.config.gb_addr_config, 0, indirect); ++ VCN, inst_idx, regUVD_GFX10_ADDR_CONFIG), ++ adev->gfx.config.gb_addr_config, 0, indirect); + } + + /** +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c +@@ -44,6 +44,7 @@ + + #define VCN_VID_SOC_ADDRESS_2_0 0x1fb00 + #define VCN1_VID_SOC_ADDRESS_3_0 0x48300 ++#define VCN1_AON_SOC_ADDRESS_3_0 0x48000 + + static const struct amdgpu_hwip_reg_entry vcn_reg_list_4_0_3[] = { + SOC15_REG_ENTRY_STR(VCN, 0, regUVD_POWER_STATUS), +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c +@@ -46,6 +46,7 @@ + + #define VCN_VID_SOC_ADDRESS_2_0 0x1fb00 + #define VCN1_VID_SOC_ADDRESS_3_0 (0x48300 + 0x38000) ++#define VCN1_AON_SOC_ADDRESS_3_0 (0x48000 + 0x38000) + + #define VCN_HARVEST_MMSCH 0 + +--- a/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/vcn_v5_0_0.c +@@ -502,7 +502,8 @@ static void vcn_v5_0_0_mc_resume_dpg_mod + + /* VCN global tiling registers */ + WREG32_SOC24_DPG_MODE(inst_idx, SOC24_DPG_MODE_OFFSET( +- VCN, 0, regUVD_GFX10_ADDR_CONFIG), adev->gfx.config.gb_addr_config, 0, indirect); ++ VCN, inst_idx, regUVD_GFX10_ADDR_CONFIG), ++ adev->gfx.config.gb_addr_config, 0, indirect); + + return; + } diff --git a/queue-6.14/drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch b/queue-6.14/drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch new file mode 100644 index 0000000000..68a8e0efec --- /dev/null +++ b/queue-6.14/drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch @@ -0,0 +1,98 @@ +From 35e4079bf1a2570abffce6ababa631afcf8ea0e5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ma=C3=ADra=20Canal?= +Date: Wed, 30 Apr 2025 17:51:52 -0300 +Subject: drm/v3d: Add job to pending list if the reset was skipped +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Maíra Canal + +commit 35e4079bf1a2570abffce6ababa631afcf8ea0e5 upstream. + +When a CL/CSD job times out, we check if the GPU has made any progress +since the last timeout. If so, instead of resetting the hardware, we skip +the reset and let the timer get rearmed. This gives long-running jobs a +chance to complete. + +However, when `timedout_job()` is called, the job in question is removed +from the pending list, which means it won't be automatically freed through +`free_job()`. Consequently, when we skip the reset and keep the job +running, the job won't be freed when it finally completes. + +This situation leads to a memory leak, as exposed in [1] and [2]. + +Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when +GPU is still active"), this patch ensures the job is put back on the +pending list when extending the timeout. + +Cc: stable@vger.kernel.org # 6.0 +Reported-by: Daivik Bhatia +Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12227 [1] +Closes: https://github.com/raspberrypi/linux/issues/6817 [2] +Reviewed-by: Iago Toral Quiroga +Acked-by: Tvrtko Ursulin +Link: https://lore.kernel.org/r/20250430210643.57924-1-mcanal@igalia.com +Signed-off-by: Maíra Canal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/v3d/v3d_sched.c | 28 +++++++++++++++++++++------- + 1 file changed, 21 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/v3d/v3d_sched.c ++++ b/drivers/gpu/drm/v3d/v3d_sched.c +@@ -746,11 +746,16 @@ v3d_gpu_reset_for_timeout(struct v3d_dev + return DRM_GPU_SCHED_STAT_NOMINAL; + } + +-/* If the current address or return address have changed, then the GPU +- * has probably made progress and we should delay the reset. This +- * could fail if the GPU got in an infinite loop in the CL, but that +- * is pretty unlikely outside of an i-g-t testcase. +- */ ++static void ++v3d_sched_skip_reset(struct drm_sched_job *sched_job) ++{ ++ struct drm_gpu_scheduler *sched = sched_job->sched; ++ ++ spin_lock(&sched->job_list_lock); ++ list_add(&sched_job->list, &sched->pending_list); ++ spin_unlock(&sched->job_list_lock); ++} ++ + static enum drm_gpu_sched_stat + v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q, + u32 *timedout_ctca, u32 *timedout_ctra) +@@ -760,9 +765,16 @@ v3d_cl_job_timedout(struct drm_sched_job + u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(q)); + u32 ctra = V3D_CORE_READ(0, V3D_CLE_CTNRA(q)); + ++ /* If the current address or return address have changed, then the GPU ++ * has probably made progress and we should delay the reset. This ++ * could fail if the GPU got in an infinite loop in the CL, but that ++ * is pretty unlikely outside of an i-g-t testcase. ++ */ + if (*timedout_ctca != ctca || *timedout_ctra != ctra) { + *timedout_ctca = ctca; + *timedout_ctra = ctra; ++ ++ v3d_sched_skip_reset(sched_job); + return DRM_GPU_SCHED_STAT_NOMINAL; + } + +@@ -802,11 +814,13 @@ v3d_csd_job_timedout(struct drm_sched_jo + struct v3d_dev *v3d = job->base.v3d; + u32 batches = V3D_CORE_READ(0, V3D_CSD_CURRENT_CFG4(v3d->ver)); + +- /* If we've made progress, skip reset and let the timer get +- * rearmed. ++ /* If we've made progress, skip reset, add the job to the pending ++ * list, and let the timer get rearmed. + */ + if (job->timedout_batches != batches) { + job->timedout_batches = batches; ++ ++ v3d_sched_skip_reset(sched_job); + return DRM_GPU_SCHED_STAT_NOMINAL; + } + diff --git a/queue-6.14/drm-xe-add-page-queue-multiplier.patch b/queue-6.14/drm-xe-add-page-queue-multiplier.patch new file mode 100644 index 0000000000..06b132ac06 --- /dev/null +++ b/queue-6.14/drm-xe-add-page-queue-multiplier.patch @@ -0,0 +1,46 @@ +From 391008f34e711253c5983b0bf52277cc43723127 Mon Sep 17 00:00:00 2001 +From: Matthew Brost +Date: Tue, 8 Apr 2025 08:59:15 -0700 +Subject: drm/xe: Add page queue multiplier + +From: Matthew Brost + +commit 391008f34e711253c5983b0bf52277cc43723127 upstream. + +For an unknown reason the math to determine the PF queue size does is +not correct - compute UMD applications are overflowing the PF queue +which is fatal. A multippier of 8 fixes the problem. + +Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size") +Cc: stable@vger.kernel.org +Signed-off-by: Matthew Brost +Reviewed-by: Jagmeet Randhawa +Link: https://lore.kernel.org/r/20250408155915.78770-1-matthew.brost@intel.com +(cherry picked from commit 29582e0ea75c95668d168b12406e3c56cf5a73c4) +Signed-off-by: Lucas De Marchi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_gt_pagefault.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/xe/xe_gt_pagefault.c ++++ b/drivers/gpu/drm/xe/xe_gt_pagefault.c +@@ -422,9 +422,16 @@ static int xe_alloc_pf_queue(struct xe_g + num_eus = bitmap_weight(gt->fuse_topo.eu_mask_per_dss, + XE_MAX_EU_FUSE_BITS) * num_dss; + +- /* user can issue separate page faults per EU and per CS */ ++ /* ++ * user can issue separate page faults per EU and per CS ++ * ++ * XXX: Multiplier required as compute UMD are getting PF queue errors ++ * without it. Follow on why this multiplier is required. ++ */ ++#define PF_MULTIPLIER 8 + pf_queue->num_dw = +- (num_eus + XE_NUM_HW_ENGINES) * PF_MSG_LEN_DW; ++ (num_eus + XE_NUM_HW_ENGINES) * PF_MSG_LEN_DW * PF_MULTIPLIER; ++#undef PF_MULTIPLIER + + pf_queue->gt = gt; + pf_queue->data = devm_kcalloc(xe->drm.dev, pf_queue->num_dw, diff --git a/queue-6.14/iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch b/queue-6.14/iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch new file mode 100644 index 0000000000..b435f9aecf --- /dev/null +++ b/queue-6.14/iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch @@ -0,0 +1,40 @@ +From 52d349884738c346961e153f195f4c7fe186fcf4 Mon Sep 17 00:00:00 2001 +From: Jonathan Cameron +Date: Sun, 13 Apr 2025 11:34:24 +0100 +Subject: iio: adc: ad7266: Fix potential timestamp alignment issue. +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jonathan Cameron + +commit 52d349884738c346961e153f195f4c7fe186fcf4 upstream. + +On architectures where an s64 is only 32-bit aligned insufficient padding +would be left between the earlier elements and the timestamp. Use +aligned_s64 to enforce the correct placement and ensure the storage is +large enough. + +Fixes: 54e018da3141 ("iio:ad7266: Mark transfer buffer as __be16") # aligned_s64 is much newer. +Reported-by: David Lechner +Reviewed-by: Nuno Sá +Reviewed-by: David Lechner +Link: https://patch.msgid.link/20250413103443.2420727-2-jic23@kernel.org +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ad7266.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/adc/ad7266.c ++++ b/drivers/iio/adc/ad7266.c +@@ -45,7 +45,7 @@ struct ad7266_state { + */ + struct { + __be16 sample[2]; +- s64 timestamp; ++ aligned_s64 timestamp; + } data __aligned(IIO_DMA_MINALIGN); + }; + diff --git a/queue-6.14/iio-adc-ad7606-fix-serial-register-access.patch b/queue-6.14/iio-adc-ad7606-fix-serial-register-access.patch new file mode 100644 index 0000000000..f6b87cd81c --- /dev/null +++ b/queue-6.14/iio-adc-ad7606-fix-serial-register-access.patch @@ -0,0 +1,38 @@ +From f083f8a21cc785ebe3a33f756a3fa3660611f8db Mon Sep 17 00:00:00 2001 +From: Angelo Dureghello +Date: Fri, 18 Apr 2025 20:37:53 +0200 +Subject: iio: adc: ad7606: fix serial register access + +From: Angelo Dureghello + +commit f083f8a21cc785ebe3a33f756a3fa3660611f8db upstream. + +Fix register read/write routine as per datasheet. + +When reading multiple consecutive registers, only the first one is read +properly. This is due to missing chip select deassert and assert again +between first and second 16bit transfer, as shown in the datasheet +AD7606C-16, rev 0, figure 110. + +Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") +Reviewed-by: David Lechner +Signed-off-by: Angelo Dureghello +Link: https://patch.msgid.link/20250418-wip-bl-ad7606-fix-reg-access-v3-1-d5eeb440c738@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ad7606_spi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/adc/ad7606_spi.c ++++ b/drivers/iio/adc/ad7606_spi.c +@@ -165,7 +165,7 @@ static int ad7606_spi_reg_read(struct ad + { + .tx_buf = &st->d16[0], + .len = 2, +- .cs_change = 0, ++ .cs_change = 1, + }, { + .rx_buf = &st->d16[1], + .len = 2, diff --git a/queue-6.14/iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch b/queue-6.14/iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch new file mode 100644 index 0000000000..2423befddd --- /dev/null +++ b/queue-6.14/iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch @@ -0,0 +1,39 @@ +From ffbc26bc91c1f1eb3dcf5d8776e74cbae21ee13a Mon Sep 17 00:00:00 2001 +From: Jonathan Cameron +Date: Sun, 13 Apr 2025 11:34:25 +0100 +Subject: iio: adc: ad7768-1: Fix insufficient alignment of timestamp. +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jonathan Cameron + +commit ffbc26bc91c1f1eb3dcf5d8776e74cbae21ee13a upstream. + +On architectures where an s64 is not 64-bit aligned, this may result +insufficient alignment of the timestamp and the structure being too small. +Use aligned_s64 to force the alignment. + +Fixes: a1caeebab07e ("iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp()") # aligned_s64 newer +Reported-by: David Lechner +Reviewed-by: Nuno Sá +Reviewed-by: David Lechner +Link: https://patch.msgid.link/20250413103443.2420727-3-jic23@kernel.org +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ad7768-1.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/adc/ad7768-1.c ++++ b/drivers/iio/adc/ad7768-1.c +@@ -169,7 +169,7 @@ struct ad7768_state { + union { + struct { + __be32 chan; +- s64 timestamp; ++ aligned_s64 timestamp; + } scan; + __be32 d32; + u8 d8[2]; diff --git a/queue-6.14/iio-adc-rockchip-fix-clock-initialization-sequence.patch b/queue-6.14/iio-adc-rockchip-fix-clock-initialization-sequence.patch new file mode 100644 index 0000000000..449f00e2d8 --- /dev/null +++ b/queue-6.14/iio-adc-rockchip-fix-clock-initialization-sequence.patch @@ -0,0 +1,55 @@ +From 839f81de397019f55161c5982d670ac19d836173 Mon Sep 17 00:00:00 2001 +From: Simon Xue +Date: Wed, 12 Mar 2025 14:20:16 +0800 +Subject: iio: adc: rockchip: Fix clock initialization sequence + +From: Simon Xue + +commit 839f81de397019f55161c5982d670ac19d836173 upstream. + +clock_set_rate should be executed after devm_clk_get_enabled. + +Fixes: 97ad10bb2901 ("iio: adc: rockchip_saradc: Make use of devm_clk_get_enabled") +Signed-off-by: Simon Xue +Reviewed-by: Heiko Stuebner +Link: https://patch.msgid.link/20250312062016.137821-1-xxm@rock-chips.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/rockchip_saradc.c | 17 ++++++++--------- + 1 file changed, 8 insertions(+), 9 deletions(-) + +--- a/drivers/iio/adc/rockchip_saradc.c ++++ b/drivers/iio/adc/rockchip_saradc.c +@@ -480,15 +480,6 @@ static int rockchip_saradc_probe(struct + if (info->reset) + rockchip_saradc_reset_controller(info->reset); + +- /* +- * Use a default value for the converter clock. +- * This may become user-configurable in the future. +- */ +- ret = clk_set_rate(info->clk, info->data->clk_rate); +- if (ret < 0) +- return dev_err_probe(&pdev->dev, ret, +- "failed to set adc clk rate\n"); +- + ret = regulator_enable(info->vref); + if (ret < 0) + return dev_err_probe(&pdev->dev, ret, +@@ -515,6 +506,14 @@ static int rockchip_saradc_probe(struct + if (IS_ERR(info->clk)) + return dev_err_probe(&pdev->dev, PTR_ERR(info->clk), + "failed to get adc clock\n"); ++ /* ++ * Use a default value for the converter clock. ++ * This may become user-configurable in the future. ++ */ ++ ret = clk_set_rate(info->clk, info->data->clk_rate); ++ if (ret < 0) ++ return dev_err_probe(&pdev->dev, ret, ++ "failed to set adc clk rate\n"); + + platform_set_drvdata(pdev, indio_dev); + diff --git a/queue-6.14/iio-adis16201-correct-inclinometer-channel-resolution.patch b/queue-6.14/iio-adis16201-correct-inclinometer-channel-resolution.patch new file mode 100644 index 0000000000..9107148f6a --- /dev/null +++ b/queue-6.14/iio-adis16201-correct-inclinometer-channel-resolution.patch @@ -0,0 +1,40 @@ +From 609bc31eca06c7408e6860d8b46311ebe45c1fef Mon Sep 17 00:00:00 2001 +From: Gabriel Shahrouzi +Date: Mon, 21 Apr 2025 09:15:39 -0400 +Subject: iio: adis16201: Correct inclinometer channel resolution + +From: Gabriel Shahrouzi + +commit 609bc31eca06c7408e6860d8b46311ebe45c1fef upstream. + +The inclinometer channels were previously defined with 14 realbits. +However, the ADIS16201 datasheet states the resolution for these output +channels is 12 bits (Page 14, text description; Page 15, table 7). + +Correct the realbits value to 12 to accurately reflect the hardware. + +Fixes: f7fe1d1dd5a5 ("staging: iio: new adis16201 driver") +Cc: stable@vger.kernel.org +Signed-off-by: Gabriel Shahrouzi +Reviewed-by: Marcelo Schmitt +Link: https://patch.msgid.link/20250421131539.912966-1-gshahrouzi@gmail.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/accel/adis16201.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/iio/accel/adis16201.c ++++ b/drivers/iio/accel/adis16201.c +@@ -211,9 +211,9 @@ static const struct iio_chan_spec adis16 + BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), + ADIS_AUX_ADC_CHAN(ADIS16201_AUX_ADC_REG, ADIS16201_SCAN_AUX_ADC, 0, 12), + ADIS_INCLI_CHAN(X, ADIS16201_XINCL_OUT_REG, ADIS16201_SCAN_INCLI_X, +- BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), ++ BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 12), + ADIS_INCLI_CHAN(Y, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y, +- BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), ++ BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 12), + IIO_CHAN_SOFT_TIMESTAMP(7) + }; + diff --git a/queue-6.14/iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch b/queue-6.14/iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch new file mode 100644 index 0000000000..2ae575959e --- /dev/null +++ b/queue-6.14/iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch @@ -0,0 +1,58 @@ +From 6ffa698674053e82e811520642db2650d00d2c01 Mon Sep 17 00:00:00 2001 +From: David Lechner +Date: Thu, 17 Apr 2025 11:52:36 -0500 +Subject: iio: chemical: pms7003: use aligned_s64 for timestamp +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: David Lechner + +commit 6ffa698674053e82e811520642db2650d00d2c01 upstream. + +Follow the pattern of other drivers and use aligned_s64 for the +timestamp. This will ensure that the timestamp is correctly aligned on +all architectures. + +Also move the unaligned.h header while touching this since it was the +only one not in alphabetical order. + +Fixes: 13e945631c2f ("iio:chemical:pms7003: Fix timestamp alignment and prevent data leak.") +Signed-off-by: David Lechner +Reviewed-by: Nuno Sá +Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-4-eafac1e22318@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/chemical/pms7003.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/iio/chemical/pms7003.c ++++ b/drivers/iio/chemical/pms7003.c +@@ -5,7 +5,6 @@ + * Copyright (c) Tomasz Duszynski + */ + +-#include + #include + #include + #include +@@ -19,6 +18,8 @@ + #include + #include + #include ++#include ++#include + + #define PMS7003_DRIVER_NAME "pms7003" + +@@ -76,7 +77,7 @@ struct pms7003_state { + /* Used to construct scan to push to the IIO buffer */ + struct { + u16 data[3]; /* PM1, PM2P5, PM10 */ +- s64 ts; ++ aligned_s64 ts; + } scan; + }; + diff --git a/queue-6.14/iio-chemical-sps30-use-aligned_s64-for-timestamp.patch b/queue-6.14/iio-chemical-sps30-use-aligned_s64-for-timestamp.patch new file mode 100644 index 0000000000..4e39df3ff9 --- /dev/null +++ b/queue-6.14/iio-chemical-sps30-use-aligned_s64-for-timestamp.patch @@ -0,0 +1,38 @@ +From bb49d940344bcb8e2b19e69d7ac86f567887ea9a Mon Sep 17 00:00:00 2001 +From: David Lechner +Date: Thu, 17 Apr 2025 11:52:37 -0500 +Subject: iio: chemical: sps30: use aligned_s64 for timestamp +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: David Lechner + +commit bb49d940344bcb8e2b19e69d7ac86f567887ea9a upstream. + +Follow the pattern of other drivers and use aligned_s64 for the +timestamp. This will ensure that the timestamp is correctly aligned on +all architectures. + +Fixes: a5bf6fdd19c3 ("iio:chemical:sps30: Fix timestamp alignment") +Signed-off-by: David Lechner +Reviewed-by: Nuno Sá +Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-5-eafac1e22318@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/chemical/sps30.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/chemical/sps30.c ++++ b/drivers/iio/chemical/sps30.c +@@ -108,7 +108,7 @@ static irqreturn_t sps30_trigger_handler + int ret; + struct { + s32 data[4]; /* PM1, PM2P5, PM4, PM10 */ +- s64 ts; ++ aligned_s64 ts; + } scan; + + mutex_lock(&state->lock); diff --git a/queue-6.14/iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch b/queue-6.14/iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch new file mode 100644 index 0000000000..974142a526 --- /dev/null +++ b/queue-6.14/iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch @@ -0,0 +1,37 @@ +From 79dabbd505210e41c88060806c92c052496dd61c Mon Sep 17 00:00:00 2001 +From: Zhang Lixu +Date: Mon, 31 Mar 2025 13:50:22 +0800 +Subject: iio: hid-sensor-prox: Fix incorrect OFFSET calculation + +From: Zhang Lixu + +commit 79dabbd505210e41c88060806c92c052496dd61c upstream. + +The OFFSET calculation in the prox_read_raw() was incorrectly using the +unit exponent, which is intended for SCALE calculations. + +Remove the incorrect OFFSET calculation and set it to a fixed value of 0. + +Cc: stable@vger.kernel.org +Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver") +Signed-off-by: Zhang Lixu +Acked-by: Srinivas Pandruvada +Link: https://patch.msgid.link/20250331055022.1149736-4-lixu.zhang@intel.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/hid-sensor-prox.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/iio/light/hid-sensor-prox.c ++++ b/drivers/iio/light/hid-sensor-prox.c +@@ -124,8 +124,7 @@ static int prox_read_raw(struct iio_dev + ret_type = prox_state->scale_precision[chan->scan_index]; + break; + case IIO_CHAN_INFO_OFFSET: +- *val = hid_sensor_convert_exponent( +- prox_state->prox_attr[chan->scan_index].unit_expo); ++ *val = 0; + ret_type = IIO_VAL_INT; + break; + case IIO_CHAN_INFO_SAMP_FREQ: diff --git a/queue-6.14/iio-hid-sensor-prox-restore-lost-scale-assignments.patch b/queue-6.14/iio-hid-sensor-prox-restore-lost-scale-assignments.patch new file mode 100644 index 0000000000..c7a16aa74e --- /dev/null +++ b/queue-6.14/iio-hid-sensor-prox-restore-lost-scale-assignments.patch @@ -0,0 +1,45 @@ +From 83ded7cfaccccd2f4041769c313b58b4c9e265ad Mon Sep 17 00:00:00 2001 +From: Zhang Lixu +Date: Mon, 31 Mar 2025 13:50:20 +0800 +Subject: iio: hid-sensor-prox: Restore lost scale assignments + +From: Zhang Lixu + +commit 83ded7cfaccccd2f4041769c313b58b4c9e265ad upstream. + +The variables `scale_pre_decml`, `scale_post_decml`, and `scale_precision` +were assigned in commit d68c592e02f6 ("iio: hid-sensor-prox: Fix scale not +correct issue"), but due to a merge conflict in +commit 9c15db92a8e5 ("Merge tag 'iio-for-5.13a' of +https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next"), +these assignments were lost. + +Add back lost assignments and replace `st->prox_attr` with +`st->prox_attr[0]` because commit 596ef5cf654b ("iio: hid-sensor-prox: Add +support for more channels") changed `prox_attr` to an array. + +Cc: stable@vger.kernel.org # 5.13+ +Fixes: 9c15db92a8e5 ("Merge tag 'iio-for-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next") +Signed-off-by: Zhang Lixu +Acked-by: Srinivas Pandruvada +Link: https://patch.msgid.link/20250331055022.1149736-2-lixu.zhang@intel.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/hid-sensor-prox.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/iio/light/hid-sensor-prox.c ++++ b/drivers/iio/light/hid-sensor-prox.c +@@ -257,6 +257,11 @@ static int prox_parse_report(struct plat + + st->num_channels = index; + ++ st->scale_precision = hid_sensor_format_scale(hsdev->usage, ++ &st->prox_attr[0], ++ &st->scale_pre_decml, ++ &st->scale_post_decml); ++ + return 0; + } + diff --git a/queue-6.14/iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch b/queue-6.14/iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch new file mode 100644 index 0000000000..b6226dee29 --- /dev/null +++ b/queue-6.14/iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch @@ -0,0 +1,96 @@ +From 8b518cdb03f5f6e06d635cbfd9583d1fdbb39bfd Mon Sep 17 00:00:00 2001 +From: Zhang Lixu +Date: Mon, 31 Mar 2025 13:50:21 +0800 +Subject: iio: hid-sensor-prox: support multi-channel SCALE calculation + +From: Zhang Lixu + +commit 8b518cdb03f5f6e06d635cbfd9583d1fdbb39bfd upstream. + +With the introduction of multi-channel support in commit 596ef5cf654b +("iio: hid-sensor-prox: Add support for more channels"), each channel +requires an independent SCALE calculation, but the existing code only +calculates SCALE for a single channel. + +Addresses the problem by modifying the driver to perform independent +SCALE calculations for each channel. + +Cc: stable@vger.kernel.org +Fixes: 596ef5cf654b ("iio: hid-sensor-prox: Add support for more channels") +Signed-off-by: Zhang Lixu +Acked-by: Srinivas Pandruvada +Link: https://patch.msgid.link/20250331055022.1149736-3-lixu.zhang@intel.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 4 ++ + drivers/iio/light/hid-sensor-prox.c | 24 +++++++++-------- + 2 files changed, 17 insertions(+), 11 deletions(-) + +--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c ++++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c +@@ -66,6 +66,10 @@ static struct { + {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0}, + {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293}, + {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0, 17453293}, ++ ++ {HID_USAGE_SENSOR_HUMAN_PRESENCE, 0, 1, 0}, ++ {HID_USAGE_SENSOR_HUMAN_PROXIMITY, 0, 1, 0}, ++ {HID_USAGE_SENSOR_HUMAN_ATTENTION, 0, 1, 0}, + }; + + static void simple_div(int dividend, int divisor, int *whole, +--- a/drivers/iio/light/hid-sensor-prox.c ++++ b/drivers/iio/light/hid-sensor-prox.c +@@ -34,9 +34,9 @@ struct prox_state { + struct iio_chan_spec channels[MAX_CHANNELS]; + u32 channel2usage[MAX_CHANNELS]; + u32 human_presence[MAX_CHANNELS]; +- int scale_pre_decml; +- int scale_post_decml; +- int scale_precision; ++ int scale_pre_decml[MAX_CHANNELS]; ++ int scale_post_decml[MAX_CHANNELS]; ++ int scale_precision[MAX_CHANNELS]; + unsigned long scan_mask[2]; /* One entry plus one terminator. */ + int num_channels; + }; +@@ -116,9 +116,12 @@ static int prox_read_raw(struct iio_dev + ret_type = IIO_VAL_INT; + break; + case IIO_CHAN_INFO_SCALE: +- *val = prox_state->scale_pre_decml; +- *val2 = prox_state->scale_post_decml; +- ret_type = prox_state->scale_precision; ++ if (chan->scan_index >= prox_state->num_channels) ++ return -EINVAL; ++ ++ *val = prox_state->scale_pre_decml[chan->scan_index]; ++ *val2 = prox_state->scale_post_decml[chan->scan_index]; ++ ret_type = prox_state->scale_precision[chan->scan_index]; + break; + case IIO_CHAN_INFO_OFFSET: + *val = hid_sensor_convert_exponent( +@@ -249,6 +252,10 @@ static int prox_parse_report(struct plat + st->prox_attr[index].size); + dev_dbg(&pdev->dev, "prox %x:%x\n", st->prox_attr[index].index, + st->prox_attr[index].report_id); ++ st->scale_precision[index] = ++ hid_sensor_format_scale(usage_id, &st->prox_attr[index], ++ &st->scale_pre_decml[index], ++ &st->scale_post_decml[index]); + index++; + } + +@@ -257,11 +264,6 @@ static int prox_parse_report(struct plat + + st->num_channels = index; + +- st->scale_precision = hid_sensor_format_scale(hsdev->usage, +- &st->prox_attr[0], +- &st->scale_pre_decml, +- &st->scale_post_decml); +- + return 0; + } + diff --git a/queue-6.14/iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch b/queue-6.14/iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch new file mode 100644 index 0000000000..135cddf57e --- /dev/null +++ b/queue-6.14/iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch @@ -0,0 +1,33 @@ +From 1d2d8524eaffc4d9a116213520d2c650e07c9cc6 Mon Sep 17 00:00:00 2001 +From: David Lechner +Date: Thu, 17 Apr 2025 11:52:39 -0500 +Subject: iio: imu: inv_mpu6050: align buffer for timestamp + +From: David Lechner + +commit 1d2d8524eaffc4d9a116213520d2c650e07c9cc6 upstream. + +Align the buffer used with iio_push_to_buffers_with_timestamp() to +ensure the s64 timestamp is aligned to 8 bytes. + +Fixes: 0829edc43e0a ("iio: imu: inv_mpu6050: read the full fifo when processing data") +Signed-off-by: David Lechner +Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-7-eafac1e22318@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c ++++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c +@@ -50,7 +50,7 @@ irqreturn_t inv_mpu6050_read_fifo(int ir + u16 fifo_count; + u32 fifo_period; + s64 timestamp; +- u8 data[INV_MPU6050_OUTPUT_DATA_SIZE]; ++ u8 data[INV_MPU6050_OUTPUT_DATA_SIZE] __aligned(8); + size_t i, nb; + + mutex_lock(&st->lock); diff --git a/queue-6.14/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch b/queue-6.14/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch new file mode 100644 index 0000000000..0fe25fee7b --- /dev/null +++ b/queue-6.14/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch @@ -0,0 +1,35 @@ +From 159ca7f18129834b6f4c7eae67de48e96c752fc9 Mon Sep 17 00:00:00 2001 +From: Silvano Seva +Date: Tue, 11 Mar 2025 09:49:47 +0100 +Subject: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo + +From: Silvano Seva + +commit 159ca7f18129834b6f4c7eae67de48e96c752fc9 upstream. + +Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case +pattern_len is equal to zero and the device FIFO is not empty. + +Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") +Signed-off-by: Silvano Seva +Acked-by: Lorenzo Bianconi +Link: https://patch.msgid.link/20250311085030.3593-2-s.seva@4sigma.it +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c ++++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +@@ -392,6 +392,9 @@ int st_lsm6dsx_read_fifo(struct st_lsm6d + if (fifo_status & cpu_to_le16(ST_LSM6DSX_FIFO_EMPTY_MASK)) + return 0; + ++ if (!pattern_len) ++ pattern_len = ST_LSM6DSX_SAMPLE_SIZE; ++ + fifo_len = (le16_to_cpu(fifo_status) & fifo_diff_mask) * + ST_LSM6DSX_CHAN_SIZE; + fifo_len = (fifo_len / pattern_len) * pattern_len; diff --git a/queue-6.14/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch b/queue-6.14/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch new file mode 100644 index 0000000000..e4414ea7ce --- /dev/null +++ b/queue-6.14/iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch @@ -0,0 +1,35 @@ +From 8114ef86e2058e2554111b793596f17bee23fa15 Mon Sep 17 00:00:00 2001 +From: Silvano Seva +Date: Tue, 11 Mar 2025 09:49:49 +0100 +Subject: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo + +From: Silvano Seva + +commit 8114ef86e2058e2554111b793596f17bee23fa15 upstream. + +Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in +case pattern_len is equal to zero and the device FIFO is not empty. + +Fixes: 801a6e0af0c6 ("iio: imu: st_lsm6dsx: add support to LSM6DSO") +Signed-off-by: Silvano Seva +Acked-by: Lorenzo Bianconi +Link: https://patch.msgid.link/20250311085030.3593-4-s.seva@4sigma.it +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c ++++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +@@ -626,6 +626,9 @@ int st_lsm6dsx_read_tagged_fifo(struct s + if (!fifo_len) + return 0; + ++ if (!pattern_len) ++ pattern_len = ST_LSM6DSX_TAGGED_SAMPLE_SIZE; ++ + for (read_len = 0; read_len < fifo_len; read_len += pattern_len) { + err = st_lsm6dsx_read_block(hw, + ST_LSM6DSX_REG_FIFO_OUT_TAG_ADDR, diff --git a/queue-6.14/iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch b/queue-6.14/iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch new file mode 100644 index 0000000000..284acabb53 --- /dev/null +++ b/queue-6.14/iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch @@ -0,0 +1,50 @@ +From f063a28002e3350088b4577c5640882bf4ea17ea Mon Sep 17 00:00:00 2001 +From: Luca Ceresoli +Date: Fri, 21 Mar 2025 19:10:00 +0100 +Subject: iio: light: opt3001: fix deadlock due to concurrent flag access + +From: Luca Ceresoli + +commit f063a28002e3350088b4577c5640882bf4ea17ea upstream. + +The threaded IRQ function in this driver is reading the flag twice: once to +lock a mutex and once to unlock it. Even though the code setting the flag +is designed to prevent it, there are subtle cases where the flag could be +true at the mutex_lock stage and false at the mutex_unlock stage. This +results in the mutex not being unlocked, resulting in a deadlock. + +Fix it by making the opt3001_irq() code generally more robust, reading the +flag into a variable and using the variable value at both stages. + +Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor") +Cc: stable@vger.kernel.org +Signed-off-by: Luca Ceresoli +Link: https://patch.msgid.link/20250321-opt3001-irq-fix-v1-1-6c520d851562@bootlin.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/opt3001.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/iio/light/opt3001.c ++++ b/drivers/iio/light/opt3001.c +@@ -788,8 +788,9 @@ static irqreturn_t opt3001_irq(int irq, + int ret; + bool wake_result_ready_queue = false; + enum iio_chan_type chan_type = opt->chip_info->chan_type; ++ bool ok_to_ignore_lock = opt->ok_to_ignore_lock; + +- if (!opt->ok_to_ignore_lock) ++ if (!ok_to_ignore_lock) + mutex_lock(&opt->lock); + + ret = i2c_smbus_read_word_swapped(opt->client, OPT3001_CONFIGURATION); +@@ -826,7 +827,7 @@ static irqreturn_t opt3001_irq(int irq, + } + + out: +- if (!opt->ok_to_ignore_lock) ++ if (!ok_to_ignore_lock) + mutex_unlock(&opt->lock); + + if (wake_result_ready_queue) diff --git a/queue-6.14/iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch b/queue-6.14/iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch new file mode 100644 index 0000000000..814ea67ef2 --- /dev/null +++ b/queue-6.14/iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch @@ -0,0 +1,65 @@ +From ffcd19e9f4cca0c8f9e23e88f968711acefbb37b Mon Sep 17 00:00:00 2001 +From: David Lechner +Date: Fri, 18 Apr 2025 11:17:14 -0500 +Subject: iio: pressure: mprls0025pa: use aligned_s64 for timestamp + +From: David Lechner + +commit ffcd19e9f4cca0c8f9e23e88f968711acefbb37b upstream. + +Follow the pattern of other drivers and use aligned_s64 for the +timestamp. This will ensure the struct itself it also 8-byte aligned. + +While touching this, convert struct mpr_chan to an anonymous struct +to consolidate the code a bit to make it easier for future readers. + +Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") +Signed-off-by: David Lechner +Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-2-d6a5d2b1c9fe@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/pressure/mprls0025pa.h | 17 ++++++----------- + 1 file changed, 6 insertions(+), 11 deletions(-) + +--- a/drivers/iio/pressure/mprls0025pa.h ++++ b/drivers/iio/pressure/mprls0025pa.h +@@ -34,16 +34,6 @@ struct iio_dev; + struct mpr_data; + struct mpr_ops; + +-/** +- * struct mpr_chan +- * @pres: pressure value +- * @ts: timestamp +- */ +-struct mpr_chan { +- s32 pres; +- s64 ts; +-}; +- + enum mpr_func_id { + MPR_FUNCTION_A, + MPR_FUNCTION_B, +@@ -69,6 +59,8 @@ enum mpr_func_id { + * reading in a loop until data is ready + * @completion: handshake from irq to read + * @chan: channel values for buffered mode ++ * @chan.pres: pressure value ++ * @chan.ts: timestamp + * @buffer: raw conversion data + */ + struct mpr_data { +@@ -87,7 +79,10 @@ struct mpr_data { + struct gpio_desc *gpiod_reset; + int irq; + struct completion completion; +- struct mpr_chan chan; ++ struct { ++ s32 pres; ++ aligned_s64 ts; ++ } chan; + u8 buffer[MPR_MEASUREMENT_RD_SIZE] __aligned(IIO_DMA_MINALIGN); + }; + diff --git a/queue-6.14/io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch b/queue-6.14/io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch new file mode 100644 index 0000000000..d40ba86b8b --- /dev/null +++ b/queue-6.14/io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch @@ -0,0 +1,46 @@ +From 687b2bae0efff9b25e071737d6af5004e6e35af5 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Wed, 7 May 2025 07:34:24 -0600 +Subject: io_uring: ensure deferred completions are flushed for multishot + +From: Jens Axboe + +commit 687b2bae0efff9b25e071737d6af5004e6e35af5 upstream. + +Multishot normally uses io_req_post_cqe() to post completions, but when +stopping it, it may finish up with a deferred completion. This is fine, +except if another multishot event triggers before the deferred completions +get flushed. If this occurs, then CQEs may get reordered in the CQ ring, +as new multishot completions get posted before the deferred ones are +flushed. This can cause confusion on the application side, if strict +ordering is required for the use case. + +When multishot posting via io_req_post_cqe(), flush any pending deferred +completions first, if any. + +Cc: stable@vger.kernel.org # 6.1+ +Reported-by: Norman Maurer +Reported-by: Christian Mazakas +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/io_uring.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/io_uring/io_uring.c ++++ b/io_uring/io_uring.c +@@ -874,6 +874,14 @@ bool io_req_post_cqe(struct io_kiocb *re + struct io_ring_ctx *ctx = req->ctx; + bool posted; + ++ /* ++ * If multishot has already posted deferred completions, ensure that ++ * those are flushed first before posting this one. If not, CQEs ++ * could get reordered. ++ */ ++ if (!wq_list_empty(&ctx->submit_state.compl_reqs)) ++ __io_submit_flush_completions(ctx); ++ + lockdep_assert(!io_wq_current_is_worker()); + lockdep_assert_held(&ctx->uring_lock); + diff --git a/queue-6.14/revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch b/queue-6.14/revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch new file mode 100644 index 0000000000..45a88e3226 --- /dev/null +++ b/queue-6.14/revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch @@ -0,0 +1,105 @@ +From d0ce1aaa8531a4a4707711cab5721374751c51b0 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Thu, 1 May 2025 13:00:16 -0400 +Subject: Revert "drm/amd: Stop evicting resources on APUs in suspend" + +From: Alex Deucher + +commit d0ce1aaa8531a4a4707711cab5721374751c51b0 upstream. + +This reverts commit 3a9626c816db901def438dc2513622e281186d39. + +This breaks S4 because we end up setting the s3/s0ix flags +even when we are entering s4 since prepare is used by both +flows. The causes both the S3/s0ix and s4 flags to be set +which breaks several checks in the driver which assume they +are mutually exclusive. + +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3634 +Cc: Mario Limonciello +Reviewed-by: Mario Limonciello +Signed-off-by: Alex Deucher +(cherry picked from commit ce8f7d95899c2869b47ea6ce0b3e5bf304b2fff4) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 -- + drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 18 ------------------ + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ++--------- + 3 files changed, 2 insertions(+), 29 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h +@@ -1593,11 +1593,9 @@ static inline void amdgpu_acpi_get_backl + #if defined(CONFIG_ACPI) && defined(CONFIG_SUSPEND) + bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev); + bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev); +-void amdgpu_choose_low_power_state(struct amdgpu_device *adev); + #else + static inline bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev) { return false; } + static inline bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev) { return false; } +-static inline void amdgpu_choose_low_power_state(struct amdgpu_device *adev) { } + #endif + + void amdgpu_register_gpu_instance(struct amdgpu_device *adev); +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +@@ -1533,22 +1533,4 @@ bool amdgpu_acpi_is_s0ix_active(struct a + #endif /* CONFIG_AMD_PMC */ + } + +-/** +- * amdgpu_choose_low_power_state +- * +- * @adev: amdgpu_device_pointer +- * +- * Choose the target low power state for the GPU +- */ +-void amdgpu_choose_low_power_state(struct amdgpu_device *adev) +-{ +- if (adev->in_runpm) +- return; +- +- if (amdgpu_acpi_is_s0ix_active(adev)) +- adev->in_s0ix = true; +- else if (amdgpu_acpi_is_s3_active(adev)) +- adev->in_s3 = true; +-} +- + #endif /* CONFIG_SUSPEND */ +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +@@ -4861,15 +4861,13 @@ int amdgpu_device_prepare(struct drm_dev + struct amdgpu_device *adev = drm_to_adev(dev); + int i, r; + +- amdgpu_choose_low_power_state(adev); +- + if (dev->switch_power_state == DRM_SWITCH_POWER_OFF) + return 0; + + /* Evict the majority of BOs before starting suspend sequence */ + r = amdgpu_device_evict_resources(adev); + if (r) +- goto unprepare; ++ return r; + + flush_delayed_work(&adev->gfx.gfx_off_delay_work); + +@@ -4880,15 +4878,10 @@ int amdgpu_device_prepare(struct drm_dev + continue; + r = adev->ip_blocks[i].version->funcs->prepare_suspend(&adev->ip_blocks[i]); + if (r) +- goto unprepare; ++ return r; + } + + return 0; +- +-unprepare: +- adev->in_s0ix = adev->in_s3 = adev->in_s4 = false; +- +- return r; + } + + /** diff --git a/queue-6.14/riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch b/queue-6.14/riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch new file mode 100644 index 0000000000..fd5c0f847f --- /dev/null +++ b/queue-6.14/riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch @@ -0,0 +1,54 @@ +From ae08d55807c099357c047dba17624b09414635dd Mon Sep 17 00:00:00 2001 +From: Nam Cao +Date: Sun, 4 May 2025 12:19:20 +0200 +Subject: riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL + +From: Nam Cao + +commit ae08d55807c099357c047dba17624b09414635dd upstream. + +When userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is not +available, the kernel crashes: + +Oops - illegal instruction [#1] + [snip] +epc : set_tagged_addr_ctrl+0x112/0x15a + ra : set_tagged_addr_ctrl+0x74/0x15a +epc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10 + [snip] +status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002 + set_tagged_addr_ctrl+0x112/0x15a + __riscv_sys_prctl+0x352/0x73c + do_trap_ecall_u+0x17c/0x20c + andle_exception+0x150/0x15c + +Fix it by checking if Supm is available. + +Fixes: 09d6775f503b ("riscv: Add support for userspace pointer masking") +Signed-off-by: Nam Cao +Cc: stable@vger.kernel.org +Reviewed-by: Samuel Holland +Link: https://lore.kernel.org/r/20250504101920.3393053-1-namcao@linutronix.de +Signed-off-by: Alexandre Ghiti +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/process.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c +index 7c244de77180..3db2c0c07acd 100644 +--- a/arch/riscv/kernel/process.c ++++ b/arch/riscv/kernel/process.c +@@ -275,6 +275,9 @@ long set_tagged_addr_ctrl(struct task_struct *task, unsigned long arg) + unsigned long pmm; + u8 pmlen; + ++ if (!riscv_has_extension_unlikely(RISCV_ISA_EXT_SUPM)) ++ return -EINVAL; ++ + if (is_compat_thread(ti)) + return -EINVAL; + +-- +2.49.0 + diff --git a/queue-6.14/series b/queue-6.14/series index 584053771b..8fc12301eb 100644 --- a/queue-6.14/series +++ b/queue-6.14/series @@ -81,3 +81,38 @@ selftests-mm-fix-build-break-when-compiling-pkey_util.c.patch kvm-x86-mmu-prevent-installing-hugepages-when-mem-attributes-are-changing.patch kvm-svm-forcibly-leave-smm-mode-on-shutdown-interception.patch drm-amd-display-shift-dmub-aux-reply-command-if-necessary.patch +riscv-fix-kernel-crash-due-to-pr_set_tagged_addr_ctrl.patch +io_uring-ensure-deferred-completions-are-flushed-for-multishot.patch +iio-adc-ad7768-1-fix-insufficient-alignment-of-timestamp.patch +iio-adc-ad7266-fix-potential-timestamp-alignment-issue.patch +iio-adc-ad7606-fix-serial-register-access.patch +iio-adc-rockchip-fix-clock-initialization-sequence.patch +iio-adis16201-correct-inclinometer-channel-resolution.patch +iio-chemical-sps30-use-aligned_s64-for-timestamp.patch +iio-chemical-pms7003-use-aligned_s64-for-timestamp.patch +iio-hid-sensor-prox-restore-lost-scale-assignments.patch +iio-hid-sensor-prox-support-multi-channel-scale-calculation.patch +iio-hid-sensor-prox-fix-incorrect-offset-calculation.patch +iio-imu-inv_mpu6050-align-buffer-for-timestamp.patch +iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_fifo.patch +iio-imu-st_lsm6dsx-fix-possible-lockup-in-st_lsm6dsx_read_tagged_fifo.patch +iio-light-opt3001-fix-deadlock-due-to-concurrent-flag-access.patch +iio-pressure-mprls0025pa-use-aligned_s64-for-timestamp.patch +revert-drm-amd-stop-evicting-resources-on-apus-in-suspend.patch +drm-v3d-add-job-to-pending-list-if-the-reset-was-skipped.patch +drm-xe-add-page-queue-multiplier.patch +drm-amdgpu-fix-pm-notifier-handling.patch +drm-amdgpu-vcn-using-separate-vcn1_aon_soc-offset.patch +drm-amd-display-fix-invalid-context-error-in-dml-helper.patch +drm-amd-display-more-liberal-vmin-vmax-update-for-freesync.patch +drm-amd-display-fix-the-checking-condition-in-dmub-aux-handling.patch +drm-amd-display-remove-incorrect-checking-in-dmub-aux-handler.patch +drm-amd-display-fix-wrong-handling-for-aux_defer-case.patch +drm-amd-display-copy-aux-read-reply-data-whenever-length-0.patch +drm-amdgpu-hdp4-use-memcfg-register-to-post-the-write-for-hdp-flush.patch +drm-amdgpu-hdp5.2-use-memcfg-register-to-post-the-write-for-hdp-flush.patch +drm-amdgpu-hdp5-use-memcfg-register-to-post-the-write-for-hdp-flush.patch +drm-amdgpu-hdp6-use-memcfg-register-to-post-the-write-for-hdp-flush.patch +drm-amdgpu-hdp7-use-memcfg-register-to-post-the-write-for-hdp-flush.patch +xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch +usb-uhci-platform-make-the-clock-really-optional.patch diff --git a/queue-6.14/usb-uhci-platform-make-the-clock-really-optional.patch b/queue-6.14/usb-uhci-platform-make-the-clock-really-optional.patch new file mode 100644 index 0000000000..e139732f58 --- /dev/null +++ b/queue-6.14/usb-uhci-platform-make-the-clock-really-optional.patch @@ -0,0 +1,39 @@ +From a5c7973539b010874a37a0e846e62ac6f00553ba Mon Sep 17 00:00:00 2001 +From: Alexey Charkov +Date: Fri, 25 Apr 2025 18:11:11 +0400 +Subject: usb: uhci-platform: Make the clock really optional + +From: Alexey Charkov + +commit a5c7973539b010874a37a0e846e62ac6f00553ba upstream. + +Device tree bindings state that the clock is optional for UHCI platform +controllers, and some existing device trees don't provide those - such +as those for VIA/WonderMedia devices. + +The driver however fails to probe now if no clock is provided, because +devm_clk_get returns an error pointer in such case. + +Switch to devm_clk_get_optional instead, so that it could probe again +on those platforms where no clocks are given. + +Cc: stable +Fixes: 26c502701c52 ("usb: uhci: Add clk support to uhci-platform") +Signed-off-by: Alexey Charkov +Link: https://lore.kernel.org/r/20250425-uhci-clock-optional-v1-1-a1d462592f29@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/uhci-platform.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/host/uhci-platform.c ++++ b/drivers/usb/host/uhci-platform.c +@@ -121,7 +121,7 @@ static int uhci_hcd_platform_probe(struc + } + + /* Get and enable clock if any specified */ +- uhci->clk = devm_clk_get(&pdev->dev, NULL); ++ uhci->clk = devm_clk_get_optional(&pdev->dev, NULL); + if (IS_ERR(uhci->clk)) { + ret = PTR_ERR(uhci->clk); + goto err_rmr; diff --git a/queue-6.14/xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch b/queue-6.14/xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch new file mode 100644 index 0000000000..1d52dd365c --- /dev/null +++ b/queue-6.14/xhci-dbc-avoid-event-polling-busyloop-if-pending-rx-transfers-are-inactive.patch @@ -0,0 +1,120 @@ +From cab63934c33b12c0d1e9f4da7450928057f2c142 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Mon, 5 May 2025 15:56:30 +0300 +Subject: xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive. +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mathias Nyman + +commit cab63934c33b12c0d1e9f4da7450928057f2c142 upstream. + +Event polling delay is set to 0 if there are any pending requests in +either rx or tx requests lists. Checking for pending requests does +not work well for "IN" transfers as the tty driver always queues +requests to the list and TRBs to the ring, preparing to receive data +from the host. + +This causes unnecessary busylooping and cpu hogging. + +Only set the event polling delay to 0 if there are pending tx "write" +transfers, or if it was less than 10ms since last active data transfer +in any direction. + +Cc: Łukasz Bartosik +Fixes: fb18e5bb9660 ("xhci: dbc: poll at different rate depending on data transfer activity") +Cc: stable@vger.kernel.org +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20250505125630.561699-3-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-dbgcap.c | 19 ++++++++++++++++--- + drivers/usb/host/xhci-dbgcap.h | 3 +++ + 2 files changed, 19 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci-dbgcap.c ++++ b/drivers/usb/host/xhci-dbgcap.c +@@ -823,6 +823,7 @@ static enum evtreturn xhci_dbc_do_handle + { + dma_addr_t deq; + union xhci_trb *evt; ++ enum evtreturn ret = EVT_DONE; + u32 ctrl, portsc; + bool update_erdp = false; + +@@ -909,6 +910,7 @@ static enum evtreturn xhci_dbc_do_handle + break; + case TRB_TYPE(TRB_TRANSFER): + dbc_handle_xfer_event(dbc, evt); ++ ret = EVT_XFER_DONE; + break; + default: + break; +@@ -927,7 +929,7 @@ static enum evtreturn xhci_dbc_do_handle + lo_hi_writeq(deq, &dbc->regs->erdp); + } + +- return EVT_DONE; ++ return ret; + } + + static void xhci_dbc_handle_events(struct work_struct *work) +@@ -936,6 +938,7 @@ static void xhci_dbc_handle_events(struc + struct xhci_dbc *dbc; + unsigned long flags; + unsigned int poll_interval; ++ unsigned long busypoll_timelimit; + + dbc = container_of(to_delayed_work(work), struct xhci_dbc, event_work); + poll_interval = dbc->poll_interval; +@@ -954,11 +957,21 @@ static void xhci_dbc_handle_events(struc + dbc->driver->disconnect(dbc); + break; + case EVT_DONE: +- /* set fast poll rate if there are pending data transfers */ ++ /* ++ * Set fast poll rate if there are pending out transfers, or ++ * a transfer was recently processed ++ */ ++ busypoll_timelimit = dbc->xfer_timestamp + ++ msecs_to_jiffies(DBC_XFER_INACTIVITY_TIMEOUT); ++ + if (!list_empty(&dbc->eps[BULK_OUT].list_pending) || +- !list_empty(&dbc->eps[BULK_IN].list_pending)) ++ time_is_after_jiffies(busypoll_timelimit)) + poll_interval = 0; + break; ++ case EVT_XFER_DONE: ++ dbc->xfer_timestamp = jiffies; ++ poll_interval = 0; ++ break; + default: + dev_info(dbc->dev, "stop handling dbc events\n"); + return; +--- a/drivers/usb/host/xhci-dbgcap.h ++++ b/drivers/usb/host/xhci-dbgcap.h +@@ -96,6 +96,7 @@ struct dbc_ep { + #define DBC_WRITE_BUF_SIZE 8192 + #define DBC_POLL_INTERVAL_DEFAULT 64 /* milliseconds */ + #define DBC_POLL_INTERVAL_MAX 5000 /* milliseconds */ ++#define DBC_XFER_INACTIVITY_TIMEOUT 10 /* milliseconds */ + /* + * Private structure for DbC hardware state: + */ +@@ -142,6 +143,7 @@ struct xhci_dbc { + enum dbc_state state; + struct delayed_work event_work; + unsigned int poll_interval; /* ms */ ++ unsigned long xfer_timestamp; + unsigned resume_required:1; + struct dbc_ep eps[2]; + +@@ -187,6 +189,7 @@ struct dbc_request { + enum evtreturn { + EVT_ERR = -1, + EVT_DONE, ++ EVT_XFER_DONE, + EVT_GSER, + EVT_DISC, + };