Re: TPM selftest failure in 4.15

Jarkko Sakkinen
2018-02-20T13:05:44Z

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