[tpmdd-devel,v2,1/4] tpm/tpm_crb: implement tpm crb idle state

The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady for
SW to indicate that the device can enter or should exit the idle state.

The legacy ACPI-start (SMI + DMA) based devices do not support these
bits and the idle state management is not exposed to the host SW.
Thus, this functionality only is enabled only for a CRB start (MMIO)
based devices.

Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
oringal patch:
'tpm_crb: implement power tpm crb power management'

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
V2: do not export the functions via tpm ops

 drivers/char/tpm/tpm_crb.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

Could you also put this into linux-kernel@vger.kernel.org?

On Mon, Sep 12, 2016 at 11:54:58AM +0300, Tomas Winkler wrote:
> The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady for
> SW to indicate that the device can enter or should exit the idle state.
> 
> The legacy ACPI-start (SMI + DMA) based devices do not support these
> bits and the idle state management is not exposed to the host SW.
> Thus, this functionality only is enabled only for a CRB start (MMIO)
> based devices.
> 
> Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> oringal patch:
> 'tpm_crb: implement power tpm crb power management'
> 
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
> V2: do not export the functions via tpm ops

I'm not sure about this. Even if callbacks are there tpm_crb and other
device drivers can use runtime PM internally (if they want).

>  drivers/char/tpm/tpm_crb.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 6e9d1bca712f..49023ac3dea1 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -83,6 +83,68 @@ struct crb_priv {
>  	u32 cmd_size;
>  };
>  
> +/**
> + * crb_go_idle - write crb_ctrl_req_go_idle to tpm_crb_ctrl_req
> + *    the device should respond within timeout_c by clearing the bit.
> + *    anyhow, we do not wait here as a consequent cmd_ready request
> + *    will be handled correctly even if idle was not completed.

Why the function descriptions have different formatting than elsewhere
in the subsystem?

> + *
> + * @dev:  crb device

'pdev' would be a better name to differentiate from character device.  I
know that in crb_acpi_add the name of the local is dev but it was just a
bad choice by me.

Also documentation could be:

@pdev:	CRB platform device

> + * @priv: crb private data

@priv:	CRB private data

> + * return:  0 always

According to

https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt

it should be 'Return:'.

Why this isn't a void function?

> + */
> +static int __maybe_unused crb_go_idle(struct device *dev, struct crb_priv *priv)
> +{
> +	if (priv->flags & crb_fl_acpi_start)
> +		return 0;
> +
> +	iowrite32(crb_ctrl_req_go_idle, &priv->cca->req);
> +	/* we don't really care when this settles */
> +
> +	return 0;
> +}
> +
> +/**
> + * crb_cmd_ready - write crb_ctrl_req_cmd_ready to tpm_crb_ctrl_req
> + *      and poll till the device acknowledge it by clearing the bit.
> + *      the device should respond within timeout_c.
> + *
> + *      the function does nothing for devices with acpi-start method
> + *
> + * @dev:  crb device
> + * @priv: crb private data
> + *
> + * return:  0 on success -etime on timeout;

Same stuff about the documentation as for the previous function.

Also, I don't like the naming. I would rather have the names I did for
[1]. There I have 'go_to_idle' and 'go_to_ready', which are much more
obvious. I'm can live also with go_ready and go_idle if you prefer that.

> + */
> +static int __maybe_unused crb_cmd_ready(struct device *dev,
> +					struct crb_priv *priv)
> +{
> +	ktime_t stop, start;
> +
> +	if (priv->flags & crb_fl_acpi_start)
> +		return 0;
> +
> +	iowrite32(crb_ctrl_req_cmd_ready, &priv->cca->req);
> +
> +	start = ktime_get();
> +	stop = ktime_add(start, ms_to_ktime(tpm2_timeout_c));
> +	do {
> +		if (!(ioread32(&priv->cca->req) & crb_ctrl_req_cmd_ready)) {
> +			dev_dbg(dev, "cmdready in %lld usecs\n",
> +				ktime_to_us(ktime_sub(ktime_get(), start)));
> +			return 0;
> +		}
> +		usleep_range(50, 100);
> +	} while (ktime_before(ktime_get(), stop));
> +
> +	if (ioread32(&priv->cca->req) & crb_ctrl_req_cmd_ready) {
> +		dev_warn(dev, "cmdready timed out\n");
> +		return -etime;
> +	}
> +
> +	return 0;
> +}
> +

Please use wait_for_tpm_stat(). Please argument in th commit message
if you don't. So far the arguments haven't made sense to me.

I think the whole status thing should be redesigned to have common
synthetized status code shared by all TPM drivers but the way I use it
in [1] works. It's bit ugly but I rather have that than duplicate code.

>  static simple_dev_pm_ops(crb_pm, tpm_pm_suspend, tpm_pm_resume);
>  
>  static u8 crb_status(struct tpm_chip *chip)
> -- 
> 2.7.4
> 

[1] http://git.infradead.org/users/jjs/linux-tpmdd.git/commitdiff/7a1172b5b3cb38083ae931309db216db3c528efe

/Jarkko

------------------------------------------------------------------------------

> -----Original Message-----
> From: Jarkko Sakkinen [mailto:jarkko.sakkinen@linux.intel.com]
> Sent: Monday, September 12, 2016 15:01
> To: Winkler, Tomas <tomas.winkler@intel.com>
> Cc: tpmdd-devel@lists.sourceforge.net; Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com>
> Subject: Re: [PATCH v2 1/4] tpm/tpm_crb: implement tpm crb idle state
> 
> Could you also put this into linux-kernel@vger.kernel.org?
> 
> On Mon, Sep 12, 2016 at 11:54:58AM +0300, Tomas Winkler wrote:
> > The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady for
> > SW to indicate that the device can enter or should exit the idle state.
> >
> > The legacy ACPI-start (SMI + DMA) based devices do not support these
> > bits and the idle state management is not exposed to the host SW.
> > Thus, this functionality only is enabled only for a CRB start (MMIO)
> > based devices.
> >
> > Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> oringal
> > patch:
> > 'tpm_crb: implement power tpm crb power management'
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> > V2: do not export the functions via tpm ops
> 
> I'm not sure about this. Even if callbacks are there tpm_crb and other device
> drivers can use runtime PM internally (if they want).
> 
> >  drivers/char/tpm/tpm_crb.c | 62
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 62 insertions(+)
> >
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index 6e9d1bca712f..49023ac3dea1 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -83,6 +83,68 @@ struct crb_priv {
> >  	u32 cmd_size;
> >  };
> >
> > +/**
> > + * crb_go_idle - write crb_ctrl_req_go_idle to tpm_crb_ctrl_req
> > + *    the device should respond within timeout_c by clearing the bit.
> > + *    anyhow, we do not wait here as a consequent cmd_ready request
> > + *    will be handled correctly even if idle was not completed.
> 
> Why the function descriptions have different formatting than elsewhere in
> the subsystem?
Oops c&p error, moved the code to much around. 
 
> 
> > + *
> > + * @dev:  crb device
> 
> 'pdev' would be a better name to differentiate from character device.  I
> know that in crb_acpi_add the name of the local is dev but it was just a bad
> choice by me.
> 
> Also documentation could be:
> 
> @pdev:	CRB platform device

I find pdev here  a bit misleading this is not a platform device, also if we want to clean up the variable names this should not be mixed within these patches. 
> 
> > + * @priv: crb private data
> 
> @priv:	CRB private data
> 
> > + * return:  0 always
> 
> According to
> 
> https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt
> 
> it should be 'Return:'.
Opps, wrong 'vi' sequence :)
> 
> Why this isn't a void function?

In general we can fail here on timeout, we just ignore it for this particular hardware.

> 	
> > + */
> > +static int __maybe_unused crb_go_idle(struct device *dev, struct
> > +crb_priv *priv) {
> > +	if (priv->flags & crb_fl_acpi_start)
> > +		return 0;
> > +
> > +	iowrite32(crb_ctrl_req_go_idle, &priv->cca->req);
> > +	/* we don't really care when this settles */
> > +
> > +	return 0;
> > +}
> > +
> > +/**
> > + * crb_cmd_ready - write crb_ctrl_req_cmd_ready to tpm_crb_ctrl_req
> > + *      and poll till the device acknowledge it by clearing the bit.
> > + *      the device should respond within timeout_c.
> > + *
> > + *      the function does nothing for devices with acpi-start method
> > + *
> > + * @dev:  crb device
> > + * @priv: crb private data
> > + *
> > + * return:  0 on success -etime on timeout;
> 
> Same stuff about the documentation as for the previous function.
Same here 'vi' sequence while pasting, will fix 

> Also, I don't like the naming. I would rather have the names I did for [1].
> There I have 'go_to_idle' and 'go_to_ready', which are much more obvious.
> I'm can live also with go_ready and go_idle if you prefer that.

go_idle and cmd_ready follow the TMP2 spec 

> > + */
> > +static int __maybe_unused crb_cmd_ready(struct device *dev,
> > +					struct crb_priv *priv)
> > +{
> > +	ktime_t stop, start;
> > +
> > +	if (priv->flags & crb_fl_acpi_start)
> > +		return 0;
> > +
> > +	iowrite32(crb_ctrl_req_cmd_ready, &priv->cca->req);
> > +
> > +	start = ktime_get();
> > +	stop = ktime_add(start, ms_to_ktime(tpm2_timeout_c));
> > +	do {
> > +		if (!(ioread32(&priv->cca->req) & crb_ctrl_req_cmd_ready)) {
> > +			dev_dbg(dev, "cmdready in %lld usecs\n",
> > +				ktime_to_us(ktime_sub(ktime_get(),
> start)));
> > +			return 0;
> > +		}
> > +		usleep_range(50, 100);
> > +	} while (ktime_before(ktime_get(), stop));
> > +
> > +	if (ioread32(&priv->cca->req) & crb_ctrl_req_cmd_ready) {
> > +		dev_warn(dev, "cmdready timed out\n");
> > +		return -etime;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> 
> Please use wait_for_tpm_stat(). Please argument in th commit message if
> you don't. So far the arguments haven't made sense to me.

I say it again this should not go via tpm_stat this is conceptually wrong.
Second why would you want to use such complex function that also cumulates side effects 
for simple polling of register that should be used at one place. Plus other reason I've mentioned before.

Last you need 'struct tpm_chip' available which just not the case here.

> I think the whole status thing should be redesigned to have common
> synthetized status code shared by all TPM drivers but the way I use it in [1]
> works. It's bit ugly but I rather have that than duplicate code.

Sorry but the such polling loops is duplicated on many places just in the tpm subsystem, 
This is not case of code duplication. 
> 
> >  static simple_dev_pm_ops(crb_pm, tpm_pm_suspend,
> tpm_pm_resume);
> >
> >  static u8 crb_status(struct tpm_chip *chip)
> > --
> > 2.7.4
> >
> 
> [1] http://git.infradead.org/users/jjs/linux-
> tpmdd.git/commitdiff/7a1172b5b3cb38083ae931309db216db3c528efe
> 
> /Jarkko

Will resend. 


------------------------------------------------------------------------------

On Mon, Sep 12, 2016 at 03:01:09PM +0300, Jarkko Sakkinen wrote:
> Could you also put this into linux-kernel@vger.kernel.org?
> 
> On Mon, Sep 12, 2016 at 11:54:58AM +0300, Tomas Winkler wrote:
> > The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady for
> > SW to indicate that the device can enter or should exit the idle state.
> > 
> > The legacy ACPI-start (SMI + DMA) based devices do not support these
> > bits and the idle state management is not exposed to the host SW.
> > Thus, this functionality only is enabled only for a CRB start (MMIO)
> > based devices.
> > 
> > Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > oringal patch:
> > 'tpm_crb: implement power tpm crb power management'
> > 
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> > V2: do not export the functions via tpm ops
> 
> I'm not sure about this. Even if callbacks are there tpm_crb and other
> device drivers can use runtime PM internally (if they want).

I give this some rethought. Using runtime PM is fine.

/Jarkko

------------------------------------------------------------------------------

> -----Original Message-----
> From: Jarkko Sakkinen [mailto:jarkko.sakkinen@linux.intel.com]
> Sent: Monday, September 12, 2016 16:32
> To: Winkler, Tomas <tomas.winkler@intel.com>
> Cc: tpmdd-devel@lists.sourceforge.net; Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com>
> Subject: Re: [PATCH v2 1/4] tpm/tpm_crb: implement tpm crb idle state
> 
> On Mon, Sep 12, 2016 at 03:01:09PM +0300, Jarkko Sakkinen wrote:
> > Could you also put this into linux-kernel@vger.kernel.org?
> >
> > On Mon, Sep 12, 2016 at 11:54:58AM +0300, Tomas Winkler wrote:
> > > The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady
> > > for SW to indicate that the device can enter or should exit the idle state.
> > >
> > > The legacy ACPI-start (SMI + DMA) based devices do not support these
> > > bits and the idle state management is not exposed to the host SW.
> > > Thus, this functionality only is enabled only for a CRB start (MMIO)
> > > based devices.
> > >
> > > Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> oringal
> > > patch:
> > > 'tpm_crb: implement power tpm crb power management'
> > >
> > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > ---
> > > V2: do not export the functions via tpm ops
> >
> > I'm not sure about this. Even if callbacks are there tpm_crb and other
> > device drivers can use runtime PM internally (if they want).
> 
> I give this some rethought. Using runtime PM is fine.

Appreciated. 
Thanks
Tomas 


------------------------------------------------------------------------------

On Mon, Sep 12, 2016 at 11:54:58AM +0300, Tomas Winkler wrote:
> The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady for
> SW to indicate that the device can enter or should exit the idle state.
> 
> The legacy ACPI-start (SMI + DMA) based devices do not support these
> bits and the idle state management is not exposed to the host SW.
> Thus, this functionality only is enabled only for a CRB start (MMIO)
> based devices.
> 
> Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> oringal patch:
> 'tpm_crb: implement power tpm crb power management'
> 
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> V2: do not export the functions via tpm ops

You need to restructure this series, do not implement functions that
are not used in a patch.

> +static int __maybe_unused crb_go_idle(struct device *dev, struct crb_priv *priv)

.. and then don't hide the warnings with maybe_unused :(

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/zohodev2dev

On Mon, Sep 12, 2016 at 12:25:21PM +0000, Winkler, Tomas wrote:

> > @pdev:	CRB platform device
> 
> I find pdev here  a bit misleading this is not a platform device,
> also if we want to clean up the variable names this should not be
> mixed within these patches.

These days within tpm core it means 'parent device'

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/zohodev2dev

On Mon, Sep 12, 2016 at 11:39:02AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 12, 2016 at 12:25:21PM +0000, Winkler, Tomas wrote:
> 
> > > @pdev:	CRB platform device
> > 
> > I find pdev here  a bit misleading this is not a platform device,
> > also if we want to clean up the variable names this should not be
> > mixed within these patches.
> 
> These days within tpm core it means 'parent device'

That's a better name, agreed. 

> Jason

/Jarkko

------------------------------------------------------------------------------
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/zohodev2dev

> 
> On Mon, Sep 12, 2016 at 11:54:58AM +0300, Tomas Winkler wrote:
> > The register TPM_CRB_CTRL_REQ_x contains bits goIdle and cmdReady for
> > SW to indicate that the device can enter or should exit the idle state.
> >
> > The legacy ACPI-start (SMI + DMA) based devices do not support these
> > bits and the idle state management is not exposed to the host SW.
> > Thus, this functionality only is enabled only for a CRB start (MMIO)
> > based devices.
> >
> > Based on Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> oringal
> > patch:
> > 'tpm_crb: implement power tpm crb power management'
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > V2: do not export the functions via tpm ops
> 
> You need to restructure this series, do not implement functions that are not
> used in a patch.

It's perfectly fine to stage patches for easier review, even if it cause harmless warning.

> > +static int __maybe_unused crb_go_idle(struct device *dev, struct
> > +crb_priv *priv)
> 
> .. and then don't hide the warnings with maybe_unused :(

This is not hiding,   the issue is that when runtime pm is not compiled and the hw bug is fixed in next gen of the hardware this function will be unused. 

Tomas


------------------------------------------------------------------------------
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/zohodev2dev

> On Mon, Sep 12, 2016 at 11:39:02AM -0600, Jason Gunthorpe wrote:
> > On Mon, Sep 12, 2016 at 12:25:21PM +0000, Winkler, Tomas wrote:
> >
> > > > @pdev:	CRB platform device
> > >
> > > I find pdev here  a bit misleading this is not a platform device,
> > > also if we want to clean up the variable names this should not be
> > > mixed within these patches.
> >
> > These days within tpm core it means 'parent device'
> 
> That's a better name, agreed.

Just the tpm_crb is the low level driver hence it this context it Is not a parent device,  the is the device :)

Tomas 

------------------------------------------------------------------------------
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/zohodev2dev

On Mon, Sep 12, 2016 at 08:26:34PM +0000, Winkler, Tomas wrote:
> > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > V2: do not export the functions via tpm ops
> > 
> > You need to restructure this series, do not implement functions that are not
> > used in a patch.
> 
> It's perfectly fine to stage patches for easier review, even if it
> cause harmless warning.

That really isn't consistent with the kernel process, please don't do
it.

> > > +static int __maybe_unused crb_go_idle(struct device *dev, struct
> > > +crb_priv *priv)
> > 
> > .. and then don't hide the warnings with maybe_unused :(
> 
> This is not hiding, the issue is that when runtime pm is not
> compiled and the hw bug is fixed in next gen of the hardware this
> function will be unused.

Hum, that might be ok, but it might be better to wrapper the functions
in the runtime pm ifdef

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/zohodev2dev

> 
> On Mon, Sep 12, 2016 at 08:26:34PM +0000, Winkler, Tomas wrote:
> > > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > > V2: do not export the functions via tpm ops
> > >
> > > You need to restructure this series, do not implement functions that
> > > are not used in a patch.
> >
> > It's perfectly fine to stage patches for easier review, even if it
> > cause harmless warning.
> 
> That really isn't consistent with the kernel process, please don't do it.

Fortunately none of us is a priest of the kernel process :),  I have some mileage in kernel too, and I agree it's not so encouraged but it's okay to easy on review.

> 
> > > > +static int __maybe_unused crb_go_idle(struct device *dev, struct
> > > > +crb_priv *priv)
> > >
> > > .. and then don't hide the warnings with maybe_unused :(
> >
> > This is not hiding, the issue is that when runtime pm is not compiled
> > and the hw bug is fixed in next gen of the hardware this function will
> > be unused.
> 
> Hum, that might be ok, but it might be better to wrapper the functions in the
> runtime pm ifdef

This would break the hw again... right.
Thanks
Tomas 


------------------------------------------------------------------------------
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/zohodev2dev

On Mon, Sep 12, 2016 at 12:25:21PM +0000, Winkler, Tomas wrote:
> > Also, I don't like the naming. I would rather have the names I did for [1].
> > There I have 'go_to_idle' and 'go_to_ready', which are much more obvious.
> > I'm can live also with go_ready and go_idle if you prefer that.
> 
> go_idle and cmd_ready follow the TMP2 spec 

'goIdle' and 'cmdReady' are CRB specific (PTP spec). I think here it
would make sense to have readable names. 'cmd_ready' sounds like it
would be return a status code or something.

I'm open for other suggestions than the ones that I proposed abouve
but cmd_ready sounds like it would return a status code.
`
> > Please use wait_for_tpm_stat(). Please argument in th commit message if
> > you don't. So far the arguments haven't made sense to me.
> 
> I say it again this should not go via tpm_stat this is conceptually
> wrong.  Second why would you want to use such complex function that
> also cumulates side effects for simple polling of register that should
> be used at one place. Plus other reason I've mentioned before.
> 
> Last you need 'struct tpm_chip' available which just not the case here.

I do agree that the status callback and these masks that we have is a
mess.

I think the tpmdd should migrate to simple design where would have
common synthetized status codes like

enum tpm_chip_status {
	TPM_CHIP_READY = BIT(0),
	TPM_CHIP_IDLE = BIT(1),
	TPM_CHIP_CANCELED = BIT(2), /* also idle */
};

(you might want to wait for two possible end states, that's why bits 
 for states is a better idea than increasing number)

However, until we have such thing, it would make sense not to introduce
redundant code or go through the longer path and fix the status code
handling.

/Jarkko

------------------------------------------------------------------------------