On Fri, 18 Dec 2020 at 18:58:43 -0600, Scott Cheloha wrote: > Hi, > > tpm(4) is the last driver in the tree using tvtohz(9). There are no > remaining callers using tstohz(9), so if and when we remove tvtohz(9) > from tpm(4) we can remove both interfaces from the tree. > > tpm(4) is tricky because it converts timeouts from milliseconds to > ticks and then doesn't use tsleep(9) at all. It uses delay(9), which > takes a count of microseconds as argument. This complicates the > conversion to tsleep_nsec(9) because the units don't match up for any > of these delays. Also, delay(9) is incompatible with tsleep(9) > because tsleep(9) yields the CPU while delay(9) busy-waits. > > I don't know if we *need* to delay(9) here. What would happen if we > yielded the CPU with e.g. tsleep(9)? > > The attached patch changes the delays to use the correct units. This > is not the right thing, these timeouts are probably too large to spin > for in delay(9). I'm just guessing here. > > Aside: TPM_READ_TMO is *huge*. 2 minutes for a read timeout seems a > bit large. NetBSD's TPM_READ_TMO has been dropped to 2 seconds, like > the other timeouts.
Yes, this driver sucks. Its only purpose is to make certain devices suspend and resume properly and doesn't provide any actual TPM functionality. We (someone other than me) should just take NetBSD's rewrite which also adds TPM 2 support and apparently works on MSFT0101 devices which was committed and backed out in ours because it didn't work.
