linux-stable.git/drivers/firmware, branch linux-6.10.y Linux kernel stable tree firmware/sysfb: Disable sysfb for firmware buffers with unknown parent 2024-10-10T10:01:07+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-09-24T08:41:03+00:00 798130704be6ea4a3d47a353af1066d313ad7523 commit ad604f0a4c040dcb8faf44dc72db25e457c28076 upstream. The sysfb framebuffer handling only operates on graphics devices that provide the system's firmware framebuffer. If that device is not known, assume that any graphics device has been initialized by firmware. Fixes a problem on i915 where sysfb does not release the firmware framebuffer after the native graphics driver loaded. Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com> Closes: https://lore.kernel.org/dri-devel/SJ1PR11MB6129EFB8CE63D1EF6D932F94B96F2@SJ1PR11MB6129.namprd11.prod.outlook.com/ Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160 Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: b49420d6a1ae ("video/aperture: optionally match the device in sysfb_disable()") Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Helge Deller <deller@gmx.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> Cc: <stable@vger.kernel.org> # v6.11+ Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924084227.262271-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ad604f0a4c040dcb8faf44dc72db25e457c28076 upstream.

The sysfb framebuffer handling only operates on graphics devices
that provide the system's firmware framebuffer. If that device is
not known, assume that any graphics device has been initialized by
firmware.

Fixes a problem on i915 where sysfb does not release the firmware
framebuffer after the native graphics driver loaded.

Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com>
Closes: https://lore.kernel.org/dri-devel/SJ1PR11MB6129EFB8CE63D1EF6D932F94B96F2@SJ1PR11MB6129.namprd11.prod.outlook.com/
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: b49420d6a1ae ("video/aperture: optionally match the device in sysfb_disable()")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Helge Deller <deller@gmx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info>
Cc: <stable@vger.kernel.org> # v6.11+
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240924084227.262271-1-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp() 2024-10-10T10:00:47+00:00 Krzysztof Kozlowski krzysztof.kozlowski@linaro.org 2024-08-16T13:57:21+00:00 411ef1a96fbda8dc21ac1da744836f77e3da5ced commit 9c3a62c20f7fb00294a4237e287254456ba8a48b upstream. mbox_client_to_bpmp() is not used, W=1 builds: drivers/firmware/tegra/bpmp.c:28:1: error: unused function 'mbox_client_to_bpmp' [-Werror,-Wunused-function] Fixes: cdfa358b248e ("firmware: tegra: Refactor BPMP driver") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9c3a62c20f7fb00294a4237e287254456ba8a48b upstream.

mbox_client_to_bpmp() is not used, W=1 builds:

  drivers/firmware/tegra/bpmp.c:28:1: error: unused function 'mbox_client_to_bpmp' [-Werror,-Wunused-function]

Fixes: cdfa358b248e ("firmware: tegra: Refactor BPMP driver")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption 2024-10-04T14:33:36+00:00 Ard Biesheuvel ardb@kernel.org 2024-09-12T15:45:49+00:00 38d9b07d99b789efb6d8dda21f1aaad636c38993 commit 77d48d39e99170b528e4f2e9fc5d1d64cdedd386 upstream. The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. Cc: <stable@vger.kernel.org> Reported-by: Breno Leitao <leitao@debian.org> Tested-by: Usama Arif <usamaarif642@gmail.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 77d48d39e99170b528e4f2e9fc5d1d64cdedd386 upstream.

The TPM event log table is a Linux specific construct, where the data
produced by the GetEventLog() boot service is cached in memory, and
passed on to the OS using an EFI configuration table.

The use of EFI_LOADER_DATA here results in the region being left
unreserved in the E820 memory map constructed by the EFI stub, and this
is the memory description that is passed on to the incoming kernel by
kexec, which is therefore unaware that the region should be reserved.

Even though the utility of the TPM2 event log after a kexec is
questionable, any corruption might send the parsing code off into the
weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
instead, which is always treated as reserved by the E820 conversion
logic.

Cc: <stable@vger.kernel.org>
Reported-by: Breno Leitao <leitao@debian.org>
Tested-by: Usama Arif <usamaarif642@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: qcom: scm: Disable SDI and write no dump to dump mode 2024-10-04T14:32:34+00:00 Mukesh Ojha quic_mojha@quicinc.com 2024-07-08T15:53:32+00:00 b1878b6839a8378e36e939f1710612ccbd8de7af [ Upstream commit 79cb2cb8d89b7eca87e8dac031dadea4aeafeaa7 ] SDI is enabled for most of the Qualcomm SoCs and as per commit ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") it was recommended to disable SDI by mentioning it in device tree to avoid hang during watchdog or during reboot. However, for some cases if download mode tcsr register already configured from boot firmware to collect dumps and if SDI is disabled via means of mentioning it in device tree we could still end up with dump collection. Disabling SDI alone is not completely enough to disable dump mode and we also need to zero out the bits download bits from tcsr register. Current commit now, unconditionally call qcom_scm_set_download_mode() based on download_mode flag, at max if TCSR register is not mentioned or available for a SoC it will fallback to legacy way of setting download mode through command which may be no-ops or return error in case current firmware does not implements QCOM_SCM_INFO_IS_CALL_AVAIL so, at worst it does nothing if it fails. It also does to call SDI disable call if dload mode is disabled, which looks fine to do as intention is to disable dump collection even if system crashes. Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20240708155332.4056479-1-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 79cb2cb8d89b7eca87e8dac031dadea4aeafeaa7 ]

SDI is enabled for most of the Qualcomm SoCs and as per commit
ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
it was recommended to disable SDI by mentioning it in device tree
to avoid hang during watchdog or during reboot.

However, for some cases if download mode tcsr register already
configured from boot firmware to collect dumps and if SDI is
disabled via means of mentioning it in device tree we could
still end up with dump collection. Disabling SDI alone is
not completely enough to disable dump mode and we also need to
zero out the bits download bits from tcsr register.

Current commit now, unconditionally call qcom_scm_set_download_mode()
based on download_mode flag, at max if TCSR register is not mentioned
or available for a SoC it will fallback to legacy way of setting
download mode through command which may be no-ops or return error
in case current firmware does not implements QCOM_SCM_INFO_IS_CALL_AVAIL
so, at worst it does nothing if it fails.

It also does to call SDI disable call if dload mode is disabled, which
looks fine to do as intention is to disable dump collection even if
system crashes.

Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required")
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20240708155332.4056479-1-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: arm_scmi: Fix double free in OPTEE transport 2024-10-04T14:32:33+00:00 Cristian Marussi cristian.marussi@arm.com 2024-08-12T17:33:32+00:00 dc9543a4f2a5498a4a12d6d2427492a6f1a28056 [ Upstream commit e98dba934b2fc587eafb83f47ad64d9053b18ae0 ] Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack. Fixes: 5f90f189a052 ("firmware: arm_scmi: Add optee transport") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 19x19 EVK Reviewed-by: Peng Fan <peng.fan@nxp.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Message-Id: <20240812173340.3912830-2-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e98dba934b2fc587eafb83f47ad64d9053b18ae0 ]

Channels can be shared between protocols, avoid freeing the same channel
descriptors twice when unloading the stack.

Fixes: 5f90f189a052 ("firmware: arm_scmi: Add optee transport")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Peng Fan <peng.fan@nxp.com>  #i.MX95 19x19 EVK
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Message-Id: <20240812173340.3912830-2-cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire() 2024-09-18T17:25:13+00:00 Dan Carpenter dan.carpenter@linaro.org 2024-08-29T19:23:04+00:00 8c6a5a1fc02ad1d62d06897ab330693d4d27cd03 [ Upstream commit db213b0cfe3268d8b1d382b3bcc999c687a2567f ] If the __qcuefi pointer is not set, then in the original code, we would hold onto the lock. That means that if we tried to set it later, then it would cause a deadlock. Drop the lock on the error path. That's what all the callers are expecting. Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/19829bc4-1b6f-47f7-847a-e90c25749e40@stanley.mountain Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit db213b0cfe3268d8b1d382b3bcc999c687a2567f ]

If the __qcuefi pointer is not set, then in the original code, we would
hold onto the lock.  That means that if we tried to set it later, then
it would cause a deadlock.  Drop the lock on the error path.  That's
what all the callers are expecting.

Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/19829bc4-1b6f-47f7-847a-e90c25749e40@stanley.mountain
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: cs_dsp: Don't allow writes to read-only controls 2024-09-12T09:12:58+00:00 Richard Fitzgerald rf@opensource.cirrus.com 2024-07-02T11:08:09+00:00 7f093820c0844c32219e4ee96128109f0f64ab8d [ Upstream commit 62412a9357b16a4e39dc582deb2e2a682b92524c ] Add a check to cs_dsp_coeff_write_ctrl() to abort if the control is not writeable. The cs_dsp code originated as an ASoC driver (wm_adsp) where all controls were exported as ALSA controls. It relied on ALSA to enforce the read-only permission. Now that the code has been separated from ALSA/ASoC it must perform its own permission check. This isn't currently causing any problems so there shouldn't be any need to backport this. If the client of cs_dsp exposes the control as an ALSA control, it should set permissions on that ALSA control to protect it. The few uses of cs_dsp_coeff_write_ctrl() inside drivers are for writable controls. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20240702110809.16836-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 62412a9357b16a4e39dc582deb2e2a682b92524c ]

Add a check to cs_dsp_coeff_write_ctrl() to abort if the control
is not writeable.

The cs_dsp code originated as an ASoC driver (wm_adsp) where all
controls were exported as ALSA controls. It relied on ALSA to
enforce the read-only permission. Now that the code has been
separated from ALSA/ASoC it must perform its own permission check.

This isn't currently causing any problems so there shouldn't be any
need to backport this. If the client of cs_dsp exposes the control as
an ALSA control, it should set permissions on that ALSA control to
protect it. The few uses of cs_dsp_coeff_write_ctrl() inside drivers
are for writable controls.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20240702110809.16836-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: microchip: fix incorrect error report of programming:timeout on success 2024-09-04T11:30:16+00:00 Steve Wilkins steve.wilkins@raymarine.com 2024-08-09T13:47:44+00:00 c9bcc056ec11f53985a6111f078bf7c0d5f66752 [ Upstream commit 591940e22e287fb64ac07be275e343d860cb72d6 ] After successfully programming the SPI flash with an MFPS auto update image, the error sysfs attribute reports programming:timeout. This is caused by an incorrect check on the return value from wait_for_completion_timeout() in mpfs_auto_update_poll_complete(). Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support") Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 591940e22e287fb64ac07be275e343d860cb72d6 ]

After successfully programming the SPI flash with an MFPS auto update
image, the error sysfs attribute reports programming:timeout.
This is caused by an incorrect check on the return value from
wait_for_completion_timeout() in mpfs_auto_update_poll_complete().

Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Steve Wilkins <steve.wilkins@raymarine.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: qcom: scm: Mark get_wq_ctx() as atomic call 2024-09-04T11:30:12+00:00 Murali Nalajala quic_mnalajal@quicinc.com 2024-08-14T22:32:44+00:00 e40115c33c0d79c940545b6b12112aace7acd9f5 commit 9960085a3a82c58d3323c1c20b991db6045063b0 upstream. Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call. Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Cc: stable@vger.kernel.org Signed-off-by: Murali Nalajala <quic_mnalajal@quicinc.com> Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> Link: https://lore.kernel.org/r/20240814223244.40081-1-quic_uchalich@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9960085a3a82c58d3323c1c20b991db6045063b0 upstream.

Currently get_wq_ctx() is wrongly configured as a standard call. When two
SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to
resume the corresponding sleeping thread. But if get_wq_ctx() is
interrupted, goes to sleep and another SMC call is waiting to be allocated
a waitq context, it leads to a deadlock.

To avoid this get_wq_ctx() must be an atomic call and can't be a standard
SMC call. Hence mark get_wq_ctx() as a fast call.

Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic")
Cc: stable@vger.kernel.org
Signed-off-by: Murali Nalajala <quic_mnalajal@quicinc.com>
Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Link: https://lore.kernel.org/r/20240814223244.40081-1-quic_uchalich@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
video/aperture: optionally match the device in sysfb_disable() 2024-09-04T11:30:01+00:00 Alex Deucher alexander.deucher@amd.com 2024-08-21T19:11:35+00:00 17e78f43de0c6da34204cc858b4cc05671ea9acf commit b49420d6a1aeb399e5b107fc6eb8584d0860fbd7 upstream. In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. NULL pointer dereference via sysfb_disable() since the resources have already been freed by aperture_detach_platform_device() when it was called by the other device. Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not. v2: Fix build when CONFIG_SCREEN_INFO is not set v3: Move device check into the mutex Drop primary variable in aperture_remove_conflicting_pci_devices() Drop __init on pci sysfb_pci_dev_is_enabled() Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device") Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Helge Deller <deller@gmx.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240821191135.829765-1-alexander.deucher@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b49420d6a1aeb399e5b107fc6eb8584d0860fbd7 upstream.

In aperture_remove_conflicting_pci_devices(), we currently only
call sysfb_disable() on vga class devices.  This leads to the
following problem when the pimary device is not VGA compatible:

1. A PCI device with a non-VGA class is the boot display
2. That device is probed first and it is not a VGA device so
   sysfb_disable() is not called, but the device resources
   are freed by aperture_detach_platform_device()
3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()
4. NULL pointer dereference via sysfb_disable() since the resources
   have already been freed by aperture_detach_platform_device() when
   it was called by the other device.

Fix this by passing a device pointer to sysfb_disable() and checking
the device to determine if we should execute it or not.

v2: Fix build when CONFIG_SCREEN_INFO is not set
v3: Move device check into the mutex
    Drop primary variable in aperture_remove_conflicting_pci_devices()
    Drop __init on pci sysfb_pci_dev_is_enabled()

Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Helge Deller <deller@gmx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240821191135.829765-1-alexander.deucher@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>