On Thu, Jun 01, 2017 at 09:55:20AM -0700, Josh Zimmerman wrote:
> On Thu, Jun 1, 2017 at 9:39 AM, Jason Gunthorpe
> <jguntho...@obsidianresearch.com> wrote:
> > On Thu, Jun 01, 2017 at 09:33:43AM -0700, Josh Zimmerman wrote:
> >
> >> - if (dev->bus && dev->bus->shutdown) {
> >> + if (dev->class && dev->class->shutdown) {
> >> + if (initcall_debug)
> >> + dev_info(dev, "shutdown\n");
> >> + dev->class->shutdown(dev);
> >> + } else if (dev->bus && dev->bus->shutdown) {
> >> if (initcall_debug)
> >> dev_info(dev, "shutdown\n");
> >> dev->bus->shutdown(dev);
> >
> > Looking at this closer, now you definately have to change the TPM
> > patch to call through to the other shutdown methods. We can say
> > current TPM drivers have no driver->shutdown, but we cannot be sure
> > about the bus->shutdown, so may as well call both from tpm's
> > class->shutdown.
> Why can't we be sure? Could bus->shutdown methods be registered
> outside of the drivers/char/tpm/ tree?
Yes.
> > I would say this should be done after the tpm2_shutdown completes as
> > lower level shutdowns could remove register access.
>
> This doesn't necessarily work. The spec states that tpm2_shutdown
> must be the last command issued for an orderly shutdown, so if we
> call
After tpm2_shutdown is called ops must be null'd then we call down the
rest of the shutdown methods which can no longer issue TPM commands
due to ops being NULL.
Jason
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
