On Thu, 2018-02-08 at 15:10 +0200, Jarkko Sakkinen wrote: > On Thu, Feb 01, 2018 at 09:00:04PM +0100, James Bottomley wrote: > > > > On Thu, 2018-02-01 at 11:59 -0700, Jason Gunthorpe wrote: > > > > > > On Thu, Feb 01, 2018 at 07:46:04PM +0100, James Bottomley wrote: > > > > > > > > > > > > > > > I honestly don't think we should be waiting for the self test > > > > at > > > > all. > > > > We should kick it off and treat any TPM_RC_TESTING error as > > > > -EAGAIN. > > > > We're already under fire for slow boot sequences and adding 2s > > > > just > > > > to > > > > wait for the TPM to self test adds to that for no real value. > > > > > > Arguably the BIOS should have completed the selftest - this stuff > > > generally only exists to support embedded. > > > > > > I don't like the idea of EAGAIN, that just expose all our users > > > to > > > this mess. > > > > > > I would support making transmit_cmd genericly wait and retry if > > > the > > > TPM insists we need to wait for selftest to complete the specific > > > command though. > > > > OK, how about this then? > > > > James > > As long as there is no identified a regression it is a waste > of time to review these... 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. James
