On Tue, Aug 26, 2025 at 11:56:48AM +0300, Jarkko Sakkinen wrote: > On Tue, Aug 26, 2025 at 09:35:08AM +0100, Jonathan McDowell wrote: > > d4640c394f23 tpm: Check for completion after timeout > > 2f661f71fda1 tpm: tis: Double the timeout B to 4s > > 1dbf74e00a5f tpm: End any active auth session before shutdown > > de9e33df7762 tpm, tpm_tis: Workaround failed command reception on Infineon > > devices > > 7146dffa875c tpm, tpm_tis: Fix timeout handling when waiting for TPM status > > e3aaebcbb7c6 tpm: Clean up TPM space after command failure > > I think we're in the same line here really :-) And apologies for > over-reacting, I definitely went over the top! > > I did the marshaller/unmarshaller exactly for Rust TPM driver only in > the sense that if I got a patch set on my table doing that, it would be > the part which is complex enough that I would actually be in trouble. > So consider it like "years ahead preparation".
As per having e.g. C driver with some Rust in and all sort of ways to integrate Rust code etc. I definitely want to experiment with that type of stuff in experimental branches. It's single best way to learn stuff to do integrations (factors better than "how to program") at least for me. Kernel dev is all about how sandboxes are created and not so much how to program kernel (IMHO). > > I quickly went through your list as a reality check if I have blind > spot but for the most part it is "business as usual" type of stuff, > some to change done many years ago (at least as old as tpmrm0). > > Obvious exception to the rule are bugs related to HMAC encryption > to which I think we have now a resolution. > > BR, Jarkko > BR, Jarkko
