On Wed, Jul 07, 2021 at 11:28:35AM -0700, Hao Wu wrote: > > On Jul 7, 2021, at 2:24 AM, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > > On Tue, Jul 06, 2021 at 09:31:35PM -0700, Hao Wu wrote: > >> Since kernel 4.14, there was a commit (9f3fc7bcddcb) BTW, please remove this. You have a fixes tag. > >> fixed the TPM sleep logic from msleep to usleep_range, > >> so that the TPM sleeps exactly with TPM_TIMEOUT (=5ms) afterward. > >> Before that fix, msleep(5) actually sleeps for around 15ms. > > > > What is TPM sleep logic? > It is about the commit metnioned in the description > `tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers` > https://github.com/torvalds/linux/commit/9f3fc7bcddcb51234e23494531f93ab60475e1c3 What you should do is to explain in simple terms the unwanted behaviour that you are observing, and also, *when* you observe it. E.g. does this happen when you use /dev/tpm0, or is it visible already in klog at boot time. And also: does it occur for anything you put to /dev/tpm0, or is the bug triggering for some particular TPM commands. You also need to have information what kind of Atmel chip triggers the bug. I'd presume that you have access to a machine with such chip? When you get all that figured out, you should explain how you change the existing behaviour, and why it makes sense. E.g. if you fixup timeouts, please just tell how'd you end up choosing the values that you picked. E.g. the rationale for that could come from testing and finding the "sweet spot", or perhaps the reason could be that old values worked, new ones don't. Especially in bug fixes the reasoning is *at least* as important as the the code change itself because I need to know what is going on. /Jarkko
