| Message ID | 1473670501-29281-2-git-send-email-tomas.winkler@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 ------------------------------------------------------------------------------
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. + * + * @dev: crb device + * @priv: crb private data + * Return: 0 always + */ +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; + */ +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; +} + static SIMPLE_DEV_PM_OPS(crb_pm, tpm_pm_suspend, tpm_pm_resume); static u8 crb_status(struct tpm_chip *chip)
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(+)