[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250305190229.GC354403@ziepe.ca>
Date: Wed, 5 Mar 2025 15:02:29 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Claudio Carvalho <cclaudio@...ux.ibm.com>,
Peter Huewe <peterhuewe@....de>, x86@...nel.org,
Dov Murik <dovmurik@...ux.ibm.com>, linux-coco@...ts.linux.dev,
Dionna Glaze <dionnaglaze@...gle.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
Tom Lendacky <thomas.lendacky@....com>,
Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH v2 3/6] tpm: add send_recv() ops in tpm_class_ops
On Wed, Mar 05, 2025 at 10:04:25AM +0100, Stefano Garzarella wrote:
> Jason suggested the send_recv() ops [2], which I liked, but if you prefer to
> avoid that, I can restore what we did in v1 and replace the
> TPM_CHIP_FLAG_IRQ hack with your point 2 (or use TPM_CHIP_FLAG_IRQ if you
> think it is fine).
I think it is a pretty notable simplification for the driver as it
does not need to implement send, status, req_canceled and more ops.
Given the small LOC on the core side I'd call that simplification a
win..
Jason
Powered by blists - more mailing lists