Re: TPM selftest failure in 4.15

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Fri, 2018-02-16 at 19:27 +0100, Alexander Steffen wrote:
> On 15.02.2018 13:12, Jarkko Sakkinen wrote:
> > On Fri, Feb 09, 2018 at 12:47:10PM +0100, Alexander Steffen wrote:
> > > On 09.02.2018 11:02, Jarkko Sakkinen wrote:
> > > > On Thu, Feb 08, 2018 at 09:02:00AM -0800, James Bottomley
> > > > wrote:
> > > > > There is an identified regression: the TPM driver will now
> > > > > periodically
> > > > > fail to attach.  However, there's no point reviewing until we
> > > > > agree
> > > > > what the fix is.  I was just waiting to verify this fixed my
> > > > > problem
> > > > > (which means seeing the messages it spits out proving the TPM
> > > > > has
> > > > > remained in self test).  I have now seen this and the driver
> > > > > still
> > > > > works, so I can submit a formal patch.
> > > > 
> > > > For the self-test the duration falls down to 2 seconds as the
> > > > specs do
> > > > not contain any well-defined duration for it, or at least I
> > > > haven't
> > > > found it.
> > > > 
> > > > I see three alternative ways the fix the self-test:
> > > > 
> > > > 1. Execute self-test with fullTest = YES.
> > > 
> > > I had proposed some fixes in this direction last year:
> > > https://patchwork.kernel.org/patch/10105483/
> > > https://patchwork.kernel.org/patch/10130535/
> > > 
> > > Those combine the fast test execution with fullTest = NO for
> > > spec-compliant
> > > TPMs with a fallback to fullTest = YES.
> > 
> > The first was accepted.
> > 
> > The 2nd wasn't accpeted mainly for reasons that for me only
> > acceptable
> > dependency is:
> > 
> > 1. Patch that is part of the same patch set.
> > 2. A merged commit.
> > 
> > I didn't event look at the code for the second one at that point
> > because
> > it was formally done wrong.
> 
> Ah, sorry, I thought this was the easiest solution, since it seemed 
> likely that the first patch would be merged at some point.
> 
> If a similar situation arises, should I then include the first patch
> in 
> a series together with the second, even if that means that there will
> be 
> two identical copies of the first patch (one from when it was first 
> published, one as part of the new series)? Or should I just avoid
> the 
> dependency in the second patch, though that will lead to merge
> conflicts 
> when you want accept both patches?
> 
> Alexander

Yes, it would be best to include all patches to the patch set that
have not yet been merged in order to make it self-contained and
easy test and review.

/Jarkko