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
