[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-7y5x3u6wVGFjj-@earth.li>
Date: Thu, 3 Apr 2025 21:43:19 +0100
From: Jonathan McDowell <noodles@...th.li>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Michal Suchanek <msuchanek@...e.de>, Peter Huewe <peterhuewe@....de>,
Jason Gunthorpe <jgg@...pe.ca>, linux-integrity@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm: tis: Increase the default for timeouts B and C
On Thu, Apr 03, 2025 at 09:45:21PM +0300, Jarkko Sakkinen wrote:
>On Wed, Apr 02, 2025 at 06:45:40PM +0100, Jonathan McDowell wrote:
>> On Wed, Apr 02, 2025 at 07:21:30PM +0200, Michal Suchanek wrote:
>> > With some Infineon chips the timeouts in tpm_tis_send_data (both B and
>> > C) can reach up to about 2250 ms.
>> >
>> > Extend the timeout duration to accommodate this.
>>
>> The problem here is the bump of timeout_c is going to interact poorly with
>> the Infineon errata workaround, as now we'll wait 4s instead of 200ms to
>> detect the stuck status change.
>>
>> (Also shouldn't timeout_c already end up as 750ms, as it's
>> max(TIS_SHORT_TIMEOUT, TPM2_TIMEOUT_C), and TIS_SHORT_TIMEOUT is 750 vs 200
>> for TPM2_TIMEOUT_C? That doesn't seem to be borne out by your logs, nor my
>> results.)
>
>Just noticed that the commit did not end up having fixes etc. tags:
>
>https://web.git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=de9e33df7762abbfc2a1568291f2c3a3154c6a9d
>
>Should we forward to stable?
It's a TPM bug rather than a kernel issue, so I don't think there's a
valid Fixes: for it, but it's certainly stable material in my mind.
J.
--
... "It only counts as a lie-in if you don't get dressed before tea time."
-- Steve Willison
Powered by blists - more mailing lists