Re: [PATCH 1/2] tpm: Factor out common startup code

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Sun, Jun 19, 2016 at 02:39:24PM +0200, Jarkko Sakkinen wrote:
> > Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> > Tested-by: Andrew Zamansky <andrew.zamansky-KrzQf0k3Iz9BDgjK7y7TUQ@public.gmane.org>
> 
> Couldn't tpm?_auto_startup() be static functions inside tpm-chip.c?

Why? tpm-chip is for chip functions and tpm-interface is for command
issuing functions, the startup command sequencors seem appropriately
placed...

These are still module private functions.

> > +enum TPM_OPS_FLAGS {
> > +	TPM_OPS_PROBE_TPM2 = BIT(0),
> 
> I see two alternatives here:
> 
> 1. Make this work for tpm_tis.c if it is doable.
> 2. Remove this flag and call tpm2_probe() inside tpm_i2c_nuvoton.c.
> 
> If this flag works only for a single driver, it does not bring any value.

We already have two drivers that auto probe, you don't think there
will be more? The idea is to try and remove these low level entry
points so drivers are simpler.

TIS doesn't use it because it needs to get things setup in advance for
interrupt auto-probing, which is a very TIS unique thing.

Alternatively we can drop the auto-probe from nuvoton and force it to
rely on compatible string matching to enter TPM2 mode.

Jason

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine