aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
diff options
context:
space:
mode:
authorMichal Suchanek <[email protected]>2025-04-04 08:23:14 +0000
committerJarkko Sakkinen <[email protected]>2025-05-15 01:49:15 +0000
commit2f661f71fda1fc0c42b7746ca5b7da529eb6b5be (patch)
tree39e4db48939743de7a90b081e839d0886877bbb2 /drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
parentchar: tpm: tpm-buf: Add sanity check fallback in read helpers (diff)
downloadkernel-2f661f71fda1fc0c42b7746ca5b7da529eb6b5be.tar.gz
kernel-2f661f71fda1fc0c42b7746ca5b7da529eb6b5be.zip
tpm: tis: Double the timeout B to 4s
With some Infineon chips the timeouts in tpm_tis_send_data (both B and C) can reach up to about 2250 ms. Timeout C is retried since commit de9e33df7762 ("tpm, tpm_tis: Workaround failed command reception on Infineon devices") Timeout B still needs to be extended. The problem is most commonly encountered with context related operation such as load context/save context. These are issued directly by the kernel, and there is no retry logic for them. When a filesystem is set up to use the TPM for unlocking the boot fails, and restarting the userspace service is ineffective. This is likely because ignoring a load context/save context result puts the real TPM state and the TPM state expected by the kernel out of sync. Chips known to be affected: tpm_tis IFX1522:00: 2.0 TPM (device-id 0x1D, rev-id 54) Description: SLB9672 Firmware Revision: 15.22 tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22) Firmware Revision: 7.83 tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16) Firmware Revision: 5.63 Link: https://lore.kernel.org/linux-integrity/[email protected]/ Signed-off-by: Michal Suchanek <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_device.c')
0 files changed, 0 insertions, 0 deletions