On Thu, Sep 18, 2025 at 08:50:39AM +0000, Frédéric JOUEN wrote: > Good morning All, > > > > I have created two issues into the raspberrypi linux github regarding the TPM > driver interface. > > Issues are : > > ● https://github.com/raspberrypi/linux/issues/7053
For this I'd hope to get some sort of draft of a patch at minimum (e.g. with RFC tag). It does not have to be fully working if it shows the problem. > ● https://github.com/raspberrypi/linux/issues/7054 I.e. this: https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-Version-1p06_pub.pdf It can be updated. I don't think that timeout did exist when at the time this was first implemented i.e. it's an improvement not a bug fix and thus I'd reconsider this: static u8 tpm2_ordinal_duration_index(u32 ordinal) { switch (ordinal) { /* Startup */ case TPM2_CC_STARTUP: /* 144 */ return TPM_MEDIUM; case TPM2_CC_SELF_TEST: /* 143 */ return TPM_LONG; case TPM2_CC_GET_RANDOM: /* 17B */ return TPM_LONG; case TPM2_CC_SEQUENCE_UPDATE: /* 15C */ return TPM_MEDIUM; case TPM2_CC_SEQUENCE_COMPLETE: /* 13E */ return TPM_MEDIUM; case TPM2_CC_EVENT_SEQUENCE_COMPLETE: /* 185 */ return TPM_MEDIUM; case TPM2_CC_HASH_SEQUENCE_START: /* 186 */ return TPM_MEDIUM; case TPM2_CC_VERIFY_SIGNATURE: /* 177 */ return TPM_LONG_LONG; case TPM2_CC_PCR_EXTEND: /* 182 */ return TPM_MEDIUM; case TPM2_CC_HIERARCHY_CONTROL: /* 121 */ return TPM_LONG; case TPM2_CC_HIERARCHY_CHANGE_AUTH: /* 129 */ return TPM_LONG; case TPM2_CC_GET_CAPABILITY: /* 17A */ return TPM_MEDIUM; case TPM2_CC_NV_READ: /* 14E */ return TPM_LONG; case TPM2_CC_CREATE_PRIMARY: /* 131 */ return TPM_LONG_LONG; case TPM2_CC_CREATE: /* 153 */ return TPM_LONG_LONG; case TPM2_CC_CREATE_LOADED: /* 191 */ return TPM_LONG_LONG; default: return TPM_UNDEFINED; } } It's quite horrible with all the indirection and everything and hard to patch. We'd be better of with something like static const struct { unsigned long ordinal; unsigned logn duration; /* msecs */ } tpm2_duration_map[] = { {TPM2_CC_STARTUP, 750}, {TPM2_CC_SELFTEST, 3000}, {TPM2_CC_GET_RANDOM, 2000} /* ... */ } And change tpm2_calc_ordinal_duration as: unsigned long tpm2_ordinal_to_duration(u32 ordinal) { int i; for (i = 0; i < ARRAY_SIZE(tpm2_duration_table); i++) { if (ordinal == tpm2_duration_map[i].ordinal) return tpm2_duration_map[i].duration; } return TPM2_DURATION_DEFAULT; } This essentially drops the chip parameter: as of today we have only common table from TPM2 and tpm_tis is the only driver that modifies chip->duration. Further, tpm_tis does this exactly for TPM 1 devices. If there's ever need to make it laaf driver specific it's easy enough to make a copy of the template into something like 'chip->duration_map' but right now there is no such use. I think this would be a pretty good long-term solution for this and similar issues. > > > > For both Phil Elwell redirects me to you. > > How can address these issues in a proper way ? > > > > On my side I’m currently working in SEALSQ France (a WISeKey company). > > We are about to release a new TPM device including PQC features. > > But today we are facing some troubles such as the issues listed above with > using current linux kernel. > > > > Best Regards, > > Frederic Jouen > > > Polite remark, and this also how vger works: use plain text email. The list drops HTML mail and thus your original message won't appear at lore.kernel.org (but since I responded this response luckily will). BR, Jarkko
