On Mon, 2023-03-20 at 15:47 +0200, Jarkko Sakkinen wrote: > On Mon, Mar 20, 2023 at 07:22:52AM -0400, James Bottomley wrote: > > On Mon, 2023-03-20 at 07:15 -0400, James Bottomley wrote: > > > The test for the AMD fTPM problem, which just went in, actually > > > uses the wrong function template for request_locality(). It's > > > missing an argument so the build breaks: > > > > > > drivers/char/tpm/tpm-chip.c:568:8: error: too few arguments to > > > function ‘tpm_request_locality’ > > > ret = tpm_request_locality(chip); > > > ^~~~~~~~~~~~~~~~~~~~ > > > drivers/char/tpm/tpm-chip.c:43:12: note: declared here > > > static int tpm_request_locality(struct tpm_chip *chip, int > > > locality) > > > ^~~~~~~~~~~~~~~~~~~~ > > > > > > Fix this by requesting zero locality. > > > > Actually, this is a bad interaction with the non-upstream patch to > > run the kernel in locality two to allow key policy to distinguish > > kernel release from user space release, which goes back to the > > debate over hibernation keys. I'll carry it separately until (or > > if ever) we get a resolution on how to do this. > > BTW, do you have a newer version of > > https://lore.kernel.org/linux-integrity/20230216201410.15010-1-James.Bottomley@xxxxxxxxxxxxxxxxxxxxx/ > > I'm planning to flush testing queue as I have now more bandwidth > for TPM and keyring (actually I'm looking RISC-V fTPM's at work). Hopefully next week. I'm on a business trip and conference this week, so most of my cycles have been going into that and converting the TPM2 engine to a provider, but I'm back home next week and the provider conversion is pretty much done. Regards, James