I haven't had a chance to dive into more. My wife had surgery on Friday and I've been tied up with that. My thought is to dump a couple registers and look at the state when it hits this. Was hoping to poke at it tomorrow, but back at the hospital tonight so it might be a couple more days before I have a chance. It should have locality when it hits that point, but wondering if it doesn't. 



Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone

-------- Original message --------
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date: 9/5/17 9:06 PM (GMT-07:00)
To: Laurent Bigonville <bigon@debian.org>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>, Alexander.Steffen@infineon.com, tpmdd-devel@lists.sourceforge.net
Subject: Re: [tpmdd-devel] tpm device not showing up in /dev anymore

On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote:
> Le 31/08/17 à 18:40, Jerry Snitselaar a écrit :
> > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote:
> > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit :
> > > > > Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit :
> > > > >>> An idea how to troubleshoot this?
> > > > >> Can you run git bisect on the changes between 4.11 and 4.12, so that
> > > > >> we find the offending commit? It is probably sufficient to limit the
> > > > >> search to commits that touch something in drivers/char/tpm.
> > > > >
> > > > > I'll try and keep you posted.
> > > >
> > > > OK I've been able to bisect the problem and the bad commit is:
> > > >
> > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit
> > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3
> > > > Author: Jerry Snitselaar <jsnitsel@redhat.com>
> > > > Date:   Mon Mar 27 08:46:04 2017 -0700
> > > >
> > > >      tpm_tis: convert to using locality callbacks
> > > >
> > > >      This patch converts tpm_tis to use of the new tpm class ops
> > > >      request_locality, and relinquish_locality.
> > > >
> > > >      With the move to using the callbacks, release_locality is
> > > > changed so
> > > >      that we now release the locality even if there is no
> > > > request pending.
> > > >
> > > >      This required some changes to the tpm_tis_core_init code path to
> > > >      make sure locality is requested when needed:
> > > >
> > > >        - tpm2_probe code path will end up calling
> > > > request/release through
> > > >          callbacks, so request_locality prior to tpm2_probe not needed.
> > > >
> > > >        - probe_itpm makes calls to tpm_tis_send_data which no
> > > > longer calls
> > > >          request_locality, so add request_locality prior to
> > > > tpm_tis_send_data
> > > >          calls. Also drop release_locality call in middleof
> > > > probe_itpm, and
> > > >          keep locality until release_locality called at end of
> > > > probe_itpm.
> > > >
> > > >      Cc: Peter Huewe <peterhuewe@gmx.de>
> > > >      Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > >      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> > > >      Cc: Marcel Selhorst <tpmdd@selhorst.net>
> > > >      Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
> > > >      Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > >      Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > >      Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > >
> > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44
> > > > 72f21b446e45ea1003de75902b0553deb99157fd M    drivers
> > > >
> > >
> > > I've looked again at the code in question, but could not find
> > > anything that is obviously wrong there. Locality is now
> > > requested/released at slightly different points in the process than
> > > before, but that's it. It does not seem to cause problems with the
> > > majority of TPMs, since you are the first to report any, so maybe it
> > > is a quirk that only affects this device.
> > >
> > > Perhaps Jerry can help, since this is his change?
> > >
> > > Alexander
> >
> > Getting some caffeine in me, and starting to take a look. Adding
> > Jarkko as well since this might involve the general locality changes.
> >
> > Laurent, if I send you a patch with some debugging code added, would
> > you be able to run it on that system? I wasn't running into issues
> > on the system I had with a 1.2 device, but I no longer have access
> > to it. I'll see if I can find one in our labs and reproduce it there.
>
> Yes I should be able to do that

Any findings?

/Jarkko