On Thu, Apr 03, 2025 at 01:56:37PM +0200, Michal Suchánek wrote:
On Thu, Apr 03, 2025 at 12:00:36PM +0100, Jonathan McDowell wrote:
On Wed, Apr 02, 2025 at 10:07:39PM +0200, Michal Suchánek 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.
>
> Yes, that's problematic. Is it possible to detect the errata by anything
> other than waiting for the timeout to expire?
Not that I'm aware of, nor have seen in my experimentation. It's a "stuck"
status, so the timeout is how it's detected.
OOI, have you tried back porting the fixes that are in mainline for 6.15 to
your frankenkernel? I _think_ the errata fix might end up resolving at least
the timeout for valid for you, as a side effect? We're currently rolling
them out across our fleet, but I don't have enough runtime yet to be sure
they've sorted all the timeout instances we see.
When was that merged?
It hit Linus' tree last Friday I believe.
The change I see is that sometimes EAGAIN is returned instead of ETIME
but based on the previous discussion this is unlikely to help.
That sounds like you might have picked up the version with the typo that
I posted to the list; it got fixed up before making it to mainline. The
two patches I've backported locally are in mainline as:
7146dffa875cd00e7a7f918e1fce79c7593ac1fa tpm, tpm_tis: Fix timeout handling
when waiting for TPM status
de9e33df7762abbfc2a1568291f2c3a3154c6a9d tpm, tpm_tis: Workaround failed
command reception on Infineon devices
J.
--
Can I trade this job for what's behind door 2?
