--- /dev/null
+From 3924f45d4de7250a603fd7b50379237a6a0e5adf Mon Sep 17 00:00:00 2001
+From: Wayne Lin <Wayne.Lin@amd.com>
+Date: Sun, 20 Apr 2025 17:50:03 +0800
+Subject: drm/amd/display: Copy AUX read reply data whenever length > 0
+
+From: Wayne Lin <Wayne.Lin@amd.com>
+
+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 <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Ray Wu <ray.wu@amd.com>
+Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
+Signed-off-by: Ray Wu <ray.wu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 9b540e3fe6796fec4fb1344f3be8952fc2f084d4)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 9984db63742099ee3f3cff35cf71306d10e64356 Mon Sep 17 00:00:00 2001
+From: Roman Li <Roman.Li@amd.com>
+Date: Mon, 14 Apr 2025 12:56:48 -0400
+Subject: drm/amd/display: Fix invalid context error in dml helper
+
+From: Roman Li <Roman.Li@amd.com>
+
+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 <aurabindo.pillai@amd.com>
+Signed-off-by: Roman Li <Roman.Li@amd.com>
+Signed-off-by: Ray Wu <ray.wu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From bc70e11b550d37fbd9eaed0f113ba560894f1609 Mon Sep 17 00:00:00 2001
+From: Wayne Lin <Wayne.Lin@amd.com>
+Date: Sun, 20 Apr 2025 16:29:07 +0800
+Subject: drm/amd/display: Fix the checking condition in dmub aux handling
+
+From: Wayne Lin <Wayne.Lin@amd.com>
+
+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 <ray.wu@amd.com>
+Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
+Signed-off-by: Ray Wu <ray.wu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 1db6c9e9b62e1a8912f0a281c941099fca678da3)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 65924ec69b29296845c7f628112353438e63ea56 Mon Sep 17 00:00:00 2001
+From: Wayne Lin <Wayne.Lin@amd.com>
+Date: Sun, 20 Apr 2025 19:22:14 +0800
+Subject: drm/amd/display: Fix wrong handling for AUX_DEFER case
+
+From: Wayne Lin <Wayne.Lin@amd.com>
+
+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 <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Ray Wu <ray.wu@amd.com>
+Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
+Signed-off-by: Ray Wu <ray.wu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 3637e457eb0000bc37d8bbbec95964aad2fb29fd)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From f1c6be3999d2be2673a51a9be0caf9348e254e52 Mon Sep 17 00:00:00 2001
+From: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Date: Wed, 16 Apr 2025 11:26:54 -0400
+Subject: drm/amd/display: more liberal vmin/vmax update for freesync
+
+From: Aurabindo Pillai <aurabindo.pillai@amd.com>
+
+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 <chiahsuan.chung@amd.com>
+Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Ray Wu <ray.wu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
++ }
+ }
+
+ /*
--- /dev/null
+From 396dc51b3b7ea524bf8061f478332d0039e96d5d Mon Sep 17 00:00:00 2001
+From: Wayne Lin <Wayne.Lin@amd.com>
+Date: Sun, 20 Apr 2025 16:56:54 +0800
+Subject: drm/amd/display: Remove incorrect checking in dmub aux handler
+
+From: Wayne Lin <Wayne.Lin@amd.com>
+
+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 <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Ray Wu <ray.wu@amd.com>
+Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
+Signed-off-by: Ray Wu <ray.wu@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 81b5c6fa62af62fe89ae9576f41aae37830b94cb)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 4aaffc85751da5722e858e4333e8cf0aa4b6c78f Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 1 May 2025 13:46:46 -0400
+Subject: drm/amdgpu: fix pm notifier handling
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <mario.limonciello@amd.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 06f2dcc241e7e5c681f81fbc46cacdf4bfd7d6d7)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From f690e3974755a650259a45d71456decc9c96a282 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <alexey.klimov@linaro.org>
+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 <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 5c937b4a6050316af37ef214825b6340b5e9e391)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 0e33e0f339b91eecd9558311449a3d1e728722d4 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <alexey.klimov@linaro.org>
+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 <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit a5cb344033c7598762e89255e8ff52827abb57a4)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From dbc988c689333faeeed44d5561f372ff20395304 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <alexey.klimov@linaro.org>
+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 <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 4a89b7698e771914b4d5b571600c76e2fdcbe2a9)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From ca28e80abe4219c8f1a2961ae05102d70af6dc87 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <alexey.klimov@linaro.org>
+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 <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 84141ff615951359c9a99696fd79a36c465ed847)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 5a11a2767731139bf87e667331aa2209e33a1d19 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <alexey.klimov@linaro.org>
+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 <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit dbc064adfcf9095e7d895bea87b2f75c1ab23236)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From b7e84fb708392b37e5dbb2a95db9b94a0e3f0aa2 Mon Sep 17 00:00:00 2001
+From: Ruijing Dong <ruijing.dong@amd.com>
+Date: Fri, 2 May 2025 11:19:26 -0400
+Subject: drm/amdgpu/vcn: using separate VCN1_AON_SOC offset
+
+From: Ruijing Dong <ruijing.dong@amd.com>
+
+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 <saleemkhan.jamadar@amd.com>
+Reviewed-by: Leo Liu <leo.liu@amd.com>
+Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 5c89ceda9984498b28716944633a9a01cbb2c90d)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 35e4079bf1a2570abffce6ababa631afcf8ea0e5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ma=C3=ADra=20Canal?= <mcanal@igalia.com>
+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 <mcanal@igalia.com>
+
+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 <dtgs1208@gmail.com>
+Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12227 [1]
+Closes: https://github.com/raspberrypi/linux/issues/6817 [2]
+Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
+Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
+Link: https://lore.kernel.org/r/20250430210643.57924-1-mcanal@igalia.com
+Signed-off-by: Maíra Canal <mcanal@igalia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 391008f34e711253c5983b0bf52277cc43723127 Mon Sep 17 00:00:00 2001
+From: Matthew Brost <matthew.brost@intel.com>
+Date: Tue, 8 Apr 2025 08:59:15 -0700
+Subject: drm/xe: Add page queue multiplier
+
+From: Matthew Brost <matthew.brost@intel.com>
+
+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 <matthew.brost@intel.com>
+Reviewed-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com>
+Link: https://lore.kernel.org/r/20250408155915.78770-1-matthew.brost@intel.com
+(cherry picked from commit 29582e0ea75c95668d168b12406e3c56cf5a73c4)
+Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 52d349884738c346961e153f195f4c7fe186fcf4 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+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 <Jonathan.Cameron@huawei.com>
+
+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 <dlechner@baylibre.com>
+Reviewed-by: Nuno Sá <nuno.sa@analog.com>
+Reviewed-by: David Lechner <dlechner@baylibre.com>
+Link: https://patch.msgid.link/20250413103443.2420727-2-jic23@kernel.org
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ };
+
--- /dev/null
+From f083f8a21cc785ebe3a33f756a3fa3660611f8db Mon Sep 17 00:00:00 2001
+From: Angelo Dureghello <adureghello@baylibre.com>
+Date: Fri, 18 Apr 2025 20:37:53 +0200
+Subject: iio: adc: ad7606: fix serial register access
+
+From: Angelo Dureghello <adureghello@baylibre.com>
+
+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 <dlechner@baylibre.com>
+Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
+Link: https://patch.msgid.link/20250418-wip-bl-ad7606-fix-reg-access-v3-1-d5eeb440c738@baylibre.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From ffbc26bc91c1f1eb3dcf5d8776e74cbae21ee13a Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+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 <Jonathan.Cameron@huawei.com>
+
+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 <dlechner@baylibre.com>
+Reviewed-by: Nuno Sá <nuno.sa@analog.com>
+Reviewed-by: David Lechner <dlechner@baylibre.com>
+Link: https://patch.msgid.link/20250413103443.2420727-3-jic23@kernel.org
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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];
--- /dev/null
+From 839f81de397019f55161c5982d670ac19d836173 Mon Sep 17 00:00:00 2001
+From: Simon Xue <xxm@rock-chips.com>
+Date: Wed, 12 Mar 2025 14:20:16 +0800
+Subject: iio: adc: rockchip: Fix clock initialization sequence
+
+From: Simon Xue <xxm@rock-chips.com>
+
+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 <xxm@rock-chips.com>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patch.msgid.link/20250312062016.137821-1-xxm@rock-chips.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 609bc31eca06c7408e6860d8b46311ebe45c1fef Mon Sep 17 00:00:00 2001
+From: Gabriel Shahrouzi <gshahrouzi@gmail.com>
+Date: Mon, 21 Apr 2025 09:15:39 -0400
+Subject: iio: adis16201: Correct inclinometer channel resolution
+
+From: Gabriel Shahrouzi <gshahrouzi@gmail.com>
+
+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 <gshahrouzi@gmail.com>
+Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
+Link: https://patch.msgid.link/20250421131539.912966-1-gshahrouzi@gmail.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
+ };
+
--- /dev/null
+From 6ffa698674053e82e811520642db2650d00d2c01 Mon Sep 17 00:00:00 2001
+From: David Lechner <dlechner@baylibre.com>
+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 <dlechner@baylibre.com>
+
+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 <dlechner@baylibre.com>
+Reviewed-by: Nuno Sá <nuno.sa@analog.com>
+Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-4-eafac1e22318@baylibre.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <tduszyns@gmail.com>
+ */
+
+-#include <linux/unaligned.h>
+ #include <linux/completion.h>
+ #include <linux/device.h>
+ #include <linux/errno.h>
+@@ -19,6 +18,8 @@
+ #include <linux/module.h>
+ #include <linux/mutex.h>
+ #include <linux/serdev.h>
++#include <linux/types.h>
++#include <linux/unaligned.h>
+
+ #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;
+ };
+
--- /dev/null
+From bb49d940344bcb8e2b19e69d7ac86f567887ea9a Mon Sep 17 00:00:00 2001
+From: David Lechner <dlechner@baylibre.com>
+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 <dlechner@baylibre.com>
+
+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 <dlechner@baylibre.com>
+Reviewed-by: Nuno Sá <nuno.sa@analog.com>
+Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-5-eafac1e22318@baylibre.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 79dabbd505210e41c88060806c92c052496dd61c Mon Sep 17 00:00:00 2001
+From: Zhang Lixu <lixu.zhang@intel.com>
+Date: Mon, 31 Mar 2025 13:50:22 +0800
+Subject: iio: hid-sensor-prox: Fix incorrect OFFSET calculation
+
+From: Zhang Lixu <lixu.zhang@intel.com>
+
+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 <lixu.zhang@intel.com>
+Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Link: https://patch.msgid.link/20250331055022.1149736-4-lixu.zhang@intel.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From 83ded7cfaccccd2f4041769c313b58b4c9e265ad Mon Sep 17 00:00:00 2001
+From: Zhang Lixu <lixu.zhang@intel.com>
+Date: Mon, 31 Mar 2025 13:50:20 +0800
+Subject: iio: hid-sensor-prox: Restore lost scale assignments
+
+From: Zhang Lixu <lixu.zhang@intel.com>
+
+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 <lixu.zhang@intel.com>
+Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Link: https://patch.msgid.link/20250331055022.1149736-2-lixu.zhang@intel.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 8b518cdb03f5f6e06d635cbfd9583d1fdbb39bfd Mon Sep 17 00:00:00 2001
+From: Zhang Lixu <lixu.zhang@intel.com>
+Date: Mon, 31 Mar 2025 13:50:21 +0800
+Subject: iio: hid-sensor-prox: support multi-channel SCALE calculation
+
+From: Zhang Lixu <lixu.zhang@intel.com>
+
+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 <lixu.zhang@intel.com>
+Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Link: https://patch.msgid.link/20250331055022.1149736-3-lixu.zhang@intel.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 1d2d8524eaffc4d9a116213520d2c650e07c9cc6 Mon Sep 17 00:00:00 2001
+From: David Lechner <dlechner@baylibre.com>
+Date: Thu, 17 Apr 2025 11:52:39 -0500
+Subject: iio: imu: inv_mpu6050: align buffer for timestamp
+
+From: David Lechner <dlechner@baylibre.com>
+
+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 <dlechner@baylibre.com>
+Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-7-eafac1e22318@baylibre.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 159ca7f18129834b6f4c7eae67de48e96c752fc9 Mon Sep 17 00:00:00 2001
+From: Silvano Seva <s.seva@4sigma.it>
+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 <s.seva@4sigma.it>
+
+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 <s.seva@4sigma.it>
+Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
+Link: https://patch.msgid.link/20250311085030.3593-2-s.seva@4sigma.it
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 8114ef86e2058e2554111b793596f17bee23fa15 Mon Sep 17 00:00:00 2001
+From: Silvano Seva <s.seva@4sigma.it>
+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 <s.seva@4sigma.it>
+
+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 <s.seva@4sigma.it>
+Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
+Link: https://patch.msgid.link/20250311085030.3593-4-s.seva@4sigma.it
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From f063a28002e3350088b4577c5640882bf4ea17ea Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Fri, 21 Mar 2025 19:10:00 +0100
+Subject: iio: light: opt3001: fix deadlock due to concurrent flag access
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+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 <luca.ceresoli@bootlin.com>
+Link: https://patch.msgid.link/20250321-opt3001-irq-fix-v1-1-6c520d851562@bootlin.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From ffcd19e9f4cca0c8f9e23e88f968711acefbb37b Mon Sep 17 00:00:00 2001
+From: David Lechner <dlechner@baylibre.com>
+Date: Fri, 18 Apr 2025 11:17:14 -0500
+Subject: iio: pressure: mprls0025pa: use aligned_s64 for timestamp
+
+From: David Lechner <dlechner@baylibre.com>
+
+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 <dlechner@baylibre.com>
+Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-2-d6a5d2b1c9fe@baylibre.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ };
+
--- /dev/null
+From 687b2bae0efff9b25e071737d6af5004e6e35af5 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Wed, 7 May 2025 07:34:24 -0600
+Subject: io_uring: ensure deferred completions are flushed for multishot
+
+From: Jens Axboe <axboe@kernel.dk>
+
+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 <norman_maurer@apple.com>
+Reported-by: Christian Mazakas <christian.mazakas@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From d0ce1aaa8531a4a4707711cab5721374751c51b0 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 1 May 2025 13:00:16 -0400
+Subject: Revert "drm/amd: Stop evicting resources on APUs in suspend"
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <mario.limonciello@amd.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit ce8f7d95899c2869b47ea6ce0b3e5bf304b2fff4)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
+ /**
--- /dev/null
+From ae08d55807c099357c047dba17624b09414635dd Mon Sep 17 00:00:00 2001
+From: Nam Cao <namcao@linutronix.de>
+Date: Sun, 4 May 2025 12:19:20 +0200
+Subject: riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL
+
+From: Nam Cao <namcao@linutronix.de>
+
+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 <namcao@linutronix.de>
+Cc: stable@vger.kernel.org
+Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
+Link: https://lore.kernel.org/r/20250504101920.3393053-1-namcao@linutronix.de
+Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
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
--- /dev/null
+From a5c7973539b010874a37a0e846e62ac6f00553ba Mon Sep 17 00:00:00 2001
+From: Alexey Charkov <alchark@gmail.com>
+Date: Fri, 25 Apr 2025 18:11:11 +0400
+Subject: usb: uhci-platform: Make the clock really optional
+
+From: Alexey Charkov <alchark@gmail.com>
+
+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 <stable@kernel.org>
+Fixes: 26c502701c52 ("usb: uhci: Add clk support to uhci-platform")
+Signed-off-by: Alexey Charkov <alchark@gmail.com>
+Link: https://lore.kernel.org/r/20250425-uhci-clock-optional-v1-1-a1d462592f29@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From cab63934c33b12c0d1e9f4da7450928057f2c142 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+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 <mathias.nyman@linux.intel.com>
+
+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 <ukaszb@chromium.org>
+Fixes: fb18e5bb9660 ("xhci: dbc: poll at different rate depending on data transfer activity")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250505125630.561699-3-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
+ };
projects / thirdparty / kernel / stable-queue.git / commitdiff
