Re: [PATCH v2 2/2] tpm_crb: Raise durations for Amazon NitroTPM

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 06:27:13PM +0000, Surendran Kanagaraj wrote:
> On Sat, Oct 17, 2026 at 03:40:25AM +0300, Jarkko Sakkinen wrote:
> > On Sat, Oct 17, 2026 at 03:31:32AM +0300, Jarkko Sakkinen wrote:
> > > Yeah so this needs a bit more redesign and while it is a possible
> > > way to address all these issues I don't believe it is best possible
> > > way imaginable to do something that lasts long-term.
> > >
> > > I don't want to go into concrete proposals because then I would have
> > > to really engineer the whole change while at it because I would
> > > likely try a number of approaches out. I.e. just a bit more effort
> > > and innovation please.
> >
> > I can give this:
> >
> > 1. Map the whole flow how we fluctuate values of durations.
> > 2. Think that if you were starting from zero how would you design a
> >    unified and coherent flow. This includes all the callbacks and both TPM
> >    1.x and TPM 2.0.
> > 3. Redo the flow based on that premise.
> >
> > I.e., break more things with consideration and if it goes over the
> > top then we attenuate the changes where needed.
> 
> Thanks for the pointers Jarkko. Will work out a design and send a
> proposal.

Yeah, this is also a theme, as generally the tone of kernel development
has changed to be slightly more intrusive than before in the sense that
addressing architectural issue is often better strategy than doing
minimal effort as per code changes.

This is because it is the way we actually decrease the LLM bug fix
activity. Implementation mistakes caused by the more bullish approach
has factors lower price tag, if it can affect the rate and density
of LLM storms.

This is why e.g., I've put out a patch set that departs assoc_array
from kernel, and replaces it with rhashtable. This way we destroy
nests instead of mosquitos.

> 
> Surendran

Br, Jarkko