Hi Jarkko, On Thu, 19 Dec 2024 at 17:07, Stefano Garzarella <sgarzare@xxxxxxxxxx> wrote: > > On Thu, Dec 19, 2024 at 05:40:58PM +0200, Jarkko Sakkinen wrote: > >On Thu Dec 19, 2024 at 5:35 PM EET, Stefano Garzarella wrote: > >> 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? > > > >There's only me. > > > >I don't know. > > > >What you want to put to include/linux/tpm.h anyway? > > At least tpmm_chip_alloc(), tpm2_probe(), and tpm_chip_register() > > >I have not followed this discussion. > > Let me try to summarize what we are doing: We are writing a small TPM > driver to support AMD SEV-SNP SVSM. Basically SVSM defines some sort of > hypercalls, which the guest OS can call to talk to the emulated vTPM. > > In the current version of this series, based on James' RFC, we have an > intermediate module (tpm_platform) and then another small driver > (platform_device) in arch/x86/coco/sev/core.c that registers the > callback to use. > > To avoid the intermediate driver (Jason correct me if I misunderstood), > we want to register the `tpm_chip` with its `tpm_class_ops` directly in > arch/x86/coco/sev/core.c where it's easy to use "SVSM calls" (i.e. > svsm_perform_call_protocol()). > > And here I have this problem, so I was proposing to expose these APIs. > BTW, we do have an alternative though that I proposed in the previous > email that might avoid this. Any thought on this? Thanks, Stefano
