Hi James, Maybe there is a misunderstanding. Here I am using tpm_msleep, not msleep. tpm_msleep is using usleep underlaying. See https://github.com/torvalds/linux/blob/master/drivers/char/tpm/tpm.h#L188 The reasons I choose 15ms, is because before https://github.com/torvalds/linux/commit/9f3fc7bcddcb51234e23494531f93ab60475e1c3 (Where msleep is changed to tpm_msleep (which is essentially usleep)), The actual sleep time is 15ms, thus here we change this back to 15ms to fix regression. Thanks Hao > On Sep 27, 2020, at 11:25 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, 2020-09-26 at 16:10 -0700, Hao Wu wrote: >> Resending following email in plaintext. >> >> ---- >> >> Hi James, >> >> Thanks for following up. >> >> We have actually tried change >> TPM_TIMEOUT_USECS_MIN / TPM_TIMEOUT_USECS_MAX >> according to https://patchwork.kernel.org/patch/10520247/ >> It does not solve the problem for ATMEL chip. The chips facing crash >> is >> not experimental, but happens commonly in >> the production systems we and our customers are using. >> It is widely found in Cisco 220 / 240 systems which are using >> Ateml chips. > > Well, I came up with the values in that patch by trial and error .... > all I know is they work for my nuvoton. If they're not right for you, > see if you can find what values actually do work for your TPM. The > difference between msleep and usleep_range is that the former can have > an indefinitely long timeout and the latter has a range bounded one. > If you think msleep works for you, the chances are it doesn't and > you're relying on the large upper bound to make the bug infrequent > enough for you not to see it. Playing with the values in usleep range > will help you find what the actual timeout is and eliminate the problem > for good. > > James
