linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Winkler, Tomas" <tomas.winkler@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: "tpmdd-devel@lists.sourceforge.net" 
	<tpmdd-devel@lists.sourceforge.net>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/4] tmp/tpm_crb: fix Intel PTT hw bug during idle state
Date: Sat, 8 Oct 2016 17:27:53 +0000	[thread overview]
Message-ID: <5B8DA87D05A7694D9FA63FD143655C1B542F6814@hasmsx108.ger.corp.intel.com> (raw)
In-Reply-To: <20161008170651.GA8747@intel.com>

> Subject: Re: [PATCH 2/4] tmp/tpm_crb: fix Intel PTT hw bug during idle state
> 
> On Sat, Oct 08, 2016 at 04:56:39PM +0000, Winkler, Tomas wrote:
> >
> > >
> > > On Sat, Oct 08, 2016 at 02:27:06PM +0000, Winkler, Tomas wrote:
> > > > >
> > > > > On Sat, Oct 08, 2016 at 02:59:37PM +0300, Tomas Winkler wrote:
> > > > > > From: "Winkler, Tomas" <tomas.winkler@intel.com>
> > > > > >
> > > > > > There is a HW bug in Skylake, Kabylake, and Broxton PCH Intel
> > > > > > PTT device, where most of the registers in the control area
> > > > > > except START, REQUEST, CANCEL, and LOC_CTRL lost retention
> > > > > > when the device is in the
> > > > > idle state.
> > > > > > Hence we need to bring the device to ready state before
> > > > > > accessing the other registers. The fix brings device to ready
> > > > > > state before trying to read command and response buffer
> > > > > > addresses in order to remap the for
> > > > > access.
> > > > > >
> > > > > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > > > > ---
> > > > > > V2: cmd read need to be called also before crb_init as this
> > > > > > will run self test.
> > > > > > V3: resend.
> > > > > > V4: add Kabylake to the list of effected platforms
> > > > > >
> > > > > >  drivers/char/tpm/tpm_crb.c | 47
> > > > > > ++++++++++++++++++++++++++++++++++++++--------
> > > > > >  1 file changed, 39 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/char/tpm/tpm_crb.c
> > > > > > b/drivers/char/tpm/tpm_crb.c index 0f3b3f3d12d3..4eb96b85c653
> > > > > > 100644
> > > > > > --- a/drivers/char/tpm/tpm_crb.c
> > > > > > +++ b/drivers/char/tpm/tpm_crb.c
> > > > > > @@ -319,6 +319,7 @@ static int crb_map_io(struct acpi_device
> > > > > > *device,
> > > > > struct crb_priv *priv,
> > > > > >  	struct list_head resources;
> > > > > >  	struct resource io_res;
> > > > > >  	struct device *dev = &device->dev;
> > > > > > +	u32 pa_high, pa_low;
> > > > > >  	u64 cmd_pa;
> > > > > >  	u32 cmd_size;
> > > > > >  	u64 rsp_pa;
> > > > > > @@ -346,12 +347,27 @@ static int crb_map_io(struct acpi_device
> > > > > > *device,
> > > > > struct crb_priv *priv,
> > > > > >  	if (IS_ERR(priv->cca))
> > > > > >  		return PTR_ERR(priv->cca);
> > > > > >
> > > > > > -	cmd_pa = ((u64) ioread32(&priv->cca->cmd_pa_high) << 32) |
> > > > > > -		  (u64) ioread32(&priv->cca->cmd_pa_low);
> > > > > > +	/*
> > > > > > +	 * PTT HW bug w/a: wake up the device to access
> > > > > > +	 * possibly not retained registers.
> > > > > > +	 */
> > > > > > +	ret = crb_cmd_ready(dev, priv);
> > > > > > +	if (ret)
> > > > > > +		return ret;
> > > > > > +
> > > > > > +	pa_high = ioread32(&priv->cca->cmd_pa_high);
> > > > > > +	pa_low  = ioread32(&priv->cca->cmd_pa_low);
> > > > > > +	cmd_pa = ((u64)pa_high << 32) | pa_low;
> > > > > >  	cmd_size = ioread32(&priv->cca->cmd_size);
> > > > > > +
> > > > > > +	dev_dbg(dev, "cmd_hi = %X cmd_low = %X cmd_size %X\n",
> > > > > > +		pa_high, pa_low, cmd_size);
> > > > > > +
> > > > > >  	priv->cmd = crb_map_res(dev, priv, &io_res, cmd_pa,
> cmd_size);
> > > > > > -	if (IS_ERR(priv->cmd))
> > > > > > -		return PTR_ERR(priv->cmd);
> > > > > > +	if (IS_ERR(priv->cmd)) {
> > > > > > +		ret = PTR_ERR(priv->cmd);
> > > > > > +		goto out;
> > > > > > +	}
> > > > > >
> > > > > >  	memcpy_fromio(&rsp_pa, &priv->cca->rsp_pa, 8);
> > > > > >  	rsp_pa = le64_to_cpu(rsp_pa); @@ -359,7 +375,8 @@ static
> int
> > > > > > crb_map_io(struct acpi_device *device, struct crb_priv *priv,
> > > > > >
> > > > > >  	if (cmd_pa != rsp_pa) {
> > > > > >  		priv->rsp = crb_map_res(dev, priv, &io_res, rsp_pa,
> rsp_size);
> > > > > > -		return PTR_ERR_OR_ZERO(priv->rsp);
> > > > > > +		ret = PTR_ERR_OR_ZERO(priv->rsp);
> > > > > > +		goto out;
> > > > > >  	}
> > > > > >
> > > > > >  	/* According to the PTP specification, overlapping command
> > > > > > and response @@ -367,12 +384,18 @@ static int
> > > > > > crb_map_io(struct acpi_device
> > > > > *device, struct crb_priv *priv,
> > > > > >  	 */
> > > > > >  	if (cmd_size != rsp_size) {
> > > > > >  		dev_err(dev, FW_BUG "overlapping command and
> response
> > > > > buffer sizes are not identical");
> > > > > > -		return -EINVAL;
> > > > > > +		ret = -EINVAL;
> > > > > > +		goto out;
> > > > > >  	}
> > > > > > +
> > > > > >  	priv->cmd_size = cmd_size;
> > > > > >
> > > > > >  	priv->rsp = priv->cmd;
> > > > > > -	return 0;
> > > > > > +
> > > > > > +out:
> > > > > > +	crb_go_idle(dev, priv);
> > > > > > +
> > > > > > +	return ret;
> > > > > >  }
> > > > > >
> > > > > >  static int crb_acpi_add(struct acpi_device *device) @@ -416,7
> > > > > > +439,15 @@ static int crb_acpi_add(struct acpi_device *device)
> > > > > >  	if (rc)
> > > > > >  		return rc;
> > > > > >
> > > > > > -	return crb_init(device, priv);
> > > > > > +	rc  = crb_cmd_ready(dev, priv);
> > > > > > +	if (rc)
> > > > > > +		return rc;
> > > > >
> > > > > I cannot find any valid reason why crb_map_io calls crb_go_idle
> > > > > in the except in the case of a failure. This is something I complained
> earlier.
> > > >
> > > > Haven't I've already explained that?  Each flow has to be enclosed
> > > > by cmdReady and goIdle.  There is nothing different here from the
> > > > other flows in that matter.  The assumption here is that we are
> > > > starting in the idle state bug because of the HW bug we cannot
> > > > access the registers. So the whole w/o is enclosed in the
> > > > crb_map_io.  After that we are starting from new, from the idle state.
> > >
> > > But why you have to do crb_go_idle upon returning from crb_map_io()?
> >
> > As written above it's is closed code... cmdReady  <perform the task>   goIdle.
> 
> It does extra cmdReady/goIdle. I don't really get your explanation here.
> crb_map_io() is not a utility function used after the driver has initialized.
> 
> crb_map_io() could just leave it ready so you don't have to do an explicit call
> to crb_cmd_ready() in crb_acpi_add. I think this is quite obvious.
> 
> > >
> > > > > A minor thing but the extra crb_cmd_ready is basically clutter
> > > > > to the initialization.
> > > >
> > > > The extra cmdReady is here in case runtime pm is not compiled into
> > > > the kernel and assumption here is that we are starting in the idle state.
> > > > Please remember that unfortunately we cannot detect whether we are
> > > > in ready on idle state as the status register is not retained, so
> > > > everything has to be ordered properly.
> > >
> > > Rather you it would be better not to use cmdReady/goIdle at all if
> > > kernel is not compiled with CONFIG_PM.
> >
> > ????. You have to do the initial cmdReady, and that's what the code
> > does, otherwise your driver won't work at all.  CONFIG_PM is the
> > software thing, it doesn't magically match the HW power state. So you
> > need to do cmdReady.
> 
> In every machine that I've tried so far the PTT has worked if cmdReady/goIdle
> haven't been used at all by the OS during a power cycle.

You mean BXT and SKL, right, but that's because you've been blessed with a specific BIOS that keeps it up.

> 
> I'll keep the current commit (v4 version) because it is tested quite well, no
> worries about that, but this is something where a cleanup would make sense
> later on.

No problem, though so far I believe the flow is correct.
Tomas

  reply	other threads:[~2016-10-08 17:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-08 11:59 [PATCH v4 0/4] tpm/tpm_crb: implement power management Tomas Winkler
2016-10-08 11:59 ` [PATCH v4 1/4] tpm/tpm_crb: implement tpm crb idle state Tomas Winkler
2016-10-08 16:30   ` Jarkko Sakkinen
2016-10-08 11:59 ` [PATCH 2/4] tmp/tpm_crb: fix Intel PTT hw bug during " Tomas Winkler
2016-10-08 12:50   ` Jarkko Sakkinen
2016-10-08 14:27     ` Winkler, Tomas
2016-10-08 16:00       ` Jarkko Sakkinen
2016-10-08 16:42         ` Jason Gunthorpe
2016-10-08 16:58           ` Winkler, Tomas
2016-10-08 17:08           ` Jarkko Sakkinen
2016-10-08 16:56         ` Winkler, Tomas
2016-10-08 17:06           ` Jarkko Sakkinen
2016-10-08 17:27             ` Winkler, Tomas [this message]
2016-10-08 18:53               ` [tpmdd-devel] " Winkler, Tomas
2016-10-08 11:59 ` [PATCH 3/4] tpm/tpm_crb: open code the crb_init into acpi_add Tomas Winkler
2016-10-08 11:59 ` [PATCH 4/4] tmp/tpm_crb: implement runtime pm for tpm_crb Tomas Winkler
2016-10-08 12:47   ` Jarkko Sakkinen
2016-10-08 13:37     ` Winkler, Tomas
2016-10-08 16:01       ` Jarkko Sakkinen
2016-10-08 18:18         ` Winkler, Tomas
2016-10-08 18:43           ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5B8DA87D05A7694D9FA63FD143655C1B542F6814@hasmsx108.ger.corp.intel.com \
    --to=tomas.winkler@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tpmdd-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).