From: Jarkko Sakkinen <jarkko@kernel.org>
To: Surendran Kanagaraj <surenkj@amazon.com>
Cc: Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Jonathan McDowell <noodles@earth.li>,
Breno Leitao <leitao@debian.org>,
nh-open-source@amazon.com, Alexander Graf <graf@amazon.de>,
Gunnar Kudrjavets <gunnarku@amazon.com>,
Josh Levinson <joshlev@amazon.com>
Subject: Re: [RFC PATCH v3 0/8] tpm: Rework timeout and duration handling
Date: Thu, 12 Nov 2026 20:39:47 +0200 [thread overview]
Message-ID: <avYH8zHb23JUue6C@kernel.org> (raw)
In-Reply-To: <20261112163846.97654-1-surenkj@amazon.com>
On Thu, Nov 12, 2026 at 04:38:38PM +0000, Surendran Kanagaraj wrote:
> Review of v2 [1] asked to redesign how the timeouts and durations are
> handled across TPM families and drivers. This series is my attempt
> at it. Sorry for the slow progress.
No this is great! I mean it is right even if it was in some ways wrong.
I have zero expectations that this would be exactly right at first, but
now we have something more relevant to debate.
And I think this type of paradigm shift towards more architectural
changes makes kernel development much more rewarding also for you as an
author. I don't think anyone loves that much competing with LLMs when
it comes to smaller details and random bugs.
If we don't do this, we'll all become check-and-stamp machines for LLMs.
That would be sad.
A bit more intrusive but at the same time well thought changes make LLM
attention to work for our benefit as these bots help to quickly
stabilize the landed code.
Br, Jarkko
prev parent reply other threads:[~2026-11-12 18:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 16:38 [RFC PATCH v3 0/8] tpm: Rework timeout and duration handling Surendran Kanagaraj
2026-11-12 16:38 ` [RFC PATCH v3 1/8] tpm: Add a single table for all TPM wait limits Surendran Kanagaraj
2026-11-12 16:38 ` [RFC PATCH v3 2/8] tpm: Wire the timing setup to the limits table Surendran Kanagaraj
2026-11-12 16:38 ` [RFC PATCH v3 3/8] tpm: Take command durations from " Surendran Kanagaraj
2026-11-12 16:38 ` [RFC PATCH v3 4/8] tpm: Bound core and CRB waits by " Surendran Kanagaraj
2026-11-12 16:42 ` [RFC PATCH v3 5/8] tpm: Drop the jiffies timing fields from struct tpm_chip Surendran Kanagaraj
2026-11-12 16:43 ` [RFC PATCH v3 6/8] tpm: Add the tpm.limits= parameter Surendran Kanagaraj
2026-11-12 16:45 ` [RFC PATCH v3 7/8] tpm: Show timeouts and durations for TPM 2.0 chips Surendran Kanagaraj
2026-11-12 16:46 ` [RFC PATCH v3 8/8] tpm_crb: Raise the limits for Amazon NitroTPM Surendran Kanagaraj
2026-11-12 18:39 ` Jarkko Sakkinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avYH8zHb23JUue6C@kernel.org \
--to=jarkko@kernel.org \
--cc=corbet@lwn.net \
--cc=graf@amazon.de \
--cc=gunnarku@amazon.com \
--cc=jgg@ziepe.ca \
--cc=joshlev@amazon.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=noodles@earth.li \
--cc=peterhuewe@gmx.de \
--cc=surenkj@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox