> On Dec 18, 2020, at 20:16, joshua stein <[email protected]> wrote: > > 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.
Hmmm. I guess I'll merge their latest code and see if I can get it working.
