Re: [PATCH v15 01/28] tpm: Initial step to reorganize TPM public headers

Jarkko Sakkinen
2026-02-01T22:46:43Z

On Sun, Feb 01, 2026 at 11:20:20AM -0500, Daniel P. Smith wrote:
> On 1/19/26 18:40, Jarkko Sakkinen wrote:
> > On Mon, Dec 15, 2025 at 03:32:49PM -0800, Ross Philipson wrote:
> > > Replace the existing public header tpm_command.h with the first two
> > > new public headers tpm1.h and tpm_common.h. In addition, related
> > > definitions in tpm1_cmd.c were moved to the new tpm1.h.
> > >
> > > Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> > > Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
> > > ---
> > > drivers/char/tpm/tpm-buf.c | 3 +-
> > > drivers/char/tpm/tpm1-cmd.c | 13 +-----
> > > include/keys/trusted_tpm.h | 1 -
> > > include/linux/tpm.h | 3 ++
> > > include/linux/tpm1.h | 55 +++++++++++++++++++++++
> > > include/linux/tpm_command.h | 30 -------------
> >
> > Removing tpm_command.h causes unnecessary noise.
> >
> > It would be better to retain tpm_command.h, and simply supplement
> > it with TPM2 constants.
> >
> > Also, what is the reason to not have both TPM1 and TPM2 in tpm.h?
> >
> > To put the question in other words: is there something in tpm.h that
> > would be incompatible with early boot code?
> >
> > I'd rather tweak that than have more files...
>
> Every #include in tpm.h will break in the early boot code. I don't see any
> way to avoid having one header that is the device driver header that
> integrates with mainline features and at least one header that holds the
> general TPM definitions.
>
> We will move everything that was broken out into tpm_command.h, making it
> the header with the general definitions. I would raise the question of
> whether tpm_command.h would be the best name of the file after definition
> reloactions

tpm_command.h conforms with lowest common denominator in the sense that
it in its current state it is compatible with early boot code.

I'd consolidate TPM1 and TPM2 definitions that can be shared to that
header. I guess rename is fine as long as protocol definitions are
not scattered to two headers.

BR, Jarkko