On Wed, 11 Dec 2024 at 16:00, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Wed, Dec 11, 2024 at 09:19:04AM +0100, Stefano Garzarella wrote: > > > > After that, there is no meaningful shared code here, and maybe the > > > TPM_CHIP_FLAG_IRQ hack can be avoided too. > > > > IIUC you are proposing the following steps: > > - extend tpm_class_ops to add a new send_recv() op and use it in > > tpm_try_transmit() > > Yes, that seems to be the majority of your shared code. > > > - call the code in tpm_platform_probe() directly in sev > > Yes I tried this, it's not bad, but I have a problem that I'm not sure how to solve. Basically, the functions used in tpm_platform_probe() (e.g. tpmm_chip_alloc, tpm2_probe, tpm_chip_register) are all defined in drivers/char/tpm/tpm.h And in fact all users are in drivers/char/tpm. So to use them directly in sev, we would have to move these definitions into include/linux/tpm.h or some other file in inlcude/. Is this acceptable for TPM maintainers? Otherwise we need an intermediate module in drivers/char/tpm. Here we have 2 options: 1. continue as James did by creating a platform_device. 2. or we could avoid this by just exposing a registration API invoked by sev to specify the send_recv() callback to use. I mean something like renaming tpm_platform_probe() in tpm_platform_register(), and call it in snp_init_platform_device(). WDYT? Thanks, Stefano
