On Fri, Mar 07, 2025 at 04:37:12PM +0100, Stefano Garzarella wrote: > On Thu, Mar 06, 2025 at 11:52:46PM +0200, Jarkko Sakkinen wrote: > > On Wed, Mar 05, 2025 at 03:02:29PM -0400, Jason Gunthorpe wrote: > > > 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.. > > > > I'm sorry to disagree with you on this but adding a callback for > > one leaf driver is not what I would call "a win" :-) > > IIUC in the ftpm driver (tpm_ftpm_tee.c) we could also use send_recv() and > save a memcpy() to a temporally buffer (pvt_data->resp_buf) and also that 4k > buffer allocated with the private data of the driver. > > BTW if you agree, for now I'll do something similar of what we do in the > ftpm driver (which would be what Jarkko recommended - status() returns 0, > .req_complete_mask = 0, .req_complete_val = 0) and we can discuss > send_recv() in a new series where I can include changes for the ftpm driver > too, to see whether it makes sense or not. > > WDYT? Yeah, that would work. Althought not related to this callback interface per se, also tpm-dev-common.c is one example (in a way). > > Thanks, > Stefano BR, Jarkko
