On Mon, May 14, 2018 at 02:59:36PM -0500, David R. Bild wrote:
> On Mon, May 14, 2018 at 2:31 PM, Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> >
> > On Thu, May 10, 2018 at 09:41:53AM -0500, David R. Bild wrote:
> >
> > > 3) Allow the driver to register the TPM with TPM driver, but not yet
> > > expose the TPM to userspace. Let the driver do some additional work
> > > (like set the platform hierarchy password) and then explicitly inform
> > > the TPM driver that it is safe to expose the TPM to userspace. This
> > > would be my preferred approach.
> >
> > We already have this. The driver can setup enough to use the TPM
> > framework to send commands before completing registration. We use it
> > in startup timeouts and other flows today.
>
>
> That sounds perfect. Can you point me to some usages in the code (or
> relevant functions)?
>
> This driver registers with the TPM subsystem using the "tpm_tis_spi"
> driver like this:
>
> "
> static struct spi_board_info tpm_board_info = {
> .modalias = "tpm_tis_spi",
> .max_speed_hz = 43 * 1000 * 1000, // Hz
> .chip_select = 0,
> .mode = SPI_MODE_0
> };
>
> struct spi_device *tpm = spi_new_device(spi_master, &tpm_board_info);
> "
>
> I don't see how sending of commands before completing registration.
> At the very least, the "tpm_tis_spi" driver probably has to be
> changed?
Well, tpm_tis_core_init() does it
Only the driver that calls tpm_chip_register() gets to use this
capability, so you can't use "tpm_tis_spi" and the automatic binding
if you need it.
Looks like the spi binding and tpm_tis_core_init will need some gentle
editing to allow a SPI based driver the same opportunity.
Jason
