On Mon, Jun 15, 2026 at 03:17:43PM +0300, Jarkko Sakkinen wrote:
> On Mon, Jun 15, 2026 at 05:48:43AM +0100, Daniel Golle wrote:
> > tpm_tis_core_init() releases locality 0 then immediately reclaims it via
> > tpm_chip_start(); some TPMs (e.g. Nuvoton NPCT, TPM 2.0) need a few ms
> > before granting it again, so probe fails with -1. This back-to-back
> > release/request was added with the locality claim around TPM_INT_ENABLE.
> >
> > Wait for the chip to settle after releasing the locality. A delay of
> > TPM_TIMEOUT (5 ms) in __tpm_tis_relinquish_locality() is reliable; values
> > below 3 ms are not.
> >
> > Fixes: 0ef333f5ba7f ("tpm: add request_locality before write
> > TPM_INT_ENABLE")
> > Cc: [email protected]
> > Signed-off-by: Daniel Golle <[email protected]>
>
> Can rebase to my for-next-tpm and resend v2?
I figured the fix is already in place in your tree, added by
34bc0fabf166 ("tpm: tpm_tis: Add settle time for some TPMs")
device_id 0x00FE, vendor_id 0x1050 exactly matches my TPM as well,
so please drop my patch.
Sorry for the noise...
