> On Thu, Dec 07, 2017 at 03:56:07PM +0000, Alexander.Steffen@xxxxxxxxxxxx
> wrote:
>
> > > If these are intentional, it’d be great
> > > to give some hint to the user, what effect this has.
> >
> > I agree that those error messages in their current form are not that
> > helpful for the users. But they are part of the general driver
> > architecture, and are also caused by other parts of the code
> > (e.g. when using a TPM 1.2 that is deactivated or when the platform
> > did not send a startup command). We should find a way to hide (or at
> > least mark) those kind of expected errors.
>
> Other parts of the TPM code did supresses 'expected' errors like this,
> I'm not sure if it got removed during Jarkko's cleanup though - we
> need to put stuff like that back, it should not printk for something
> like this.
Yes, I've got this task here somewhere, just no time to do it...
> For this, if we are waiting then it should compute an absolute time
> after which it will give up.
>
> Code it like this instead and get rid of the ugly 'duration' scheme.
>
> ktime_t stop = ktime_add_ns(ktime_get(), [timeout in ns]);
> do
> {
> }
> while (ktime_before(ktime_get(), stop);
Is it really that ugly? I still need delay_msec to increase the delay each round. I can see the benefit of your suggestion when it is important to get the timing exactly right (and also account for time spent elsewhere, when our code might not be executing). But in this case having delays that are approximately right (or longer than intended) is sufficient.
Anyway, from the log messages it is clear that tpm_msleep got called seven times with delays of 20/40/80/160/320/640/1280ms. But still all timestamps lie within the same second. How can this be with a cumulated delay of ~2.5s?
Also, I've just noticed that despite the name tpm_msleep calls usleep_range, not msleep. Can this have an influence? Should tpm_msleep call msleep for longer delays, as suggested by Documentation/timers/timers-howto.txt?
Alexander
