> On Jul 7, 2021, at 2:10 PM, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > 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 Thanks Jarkko for pointing the direction! I have updated the description and sent a new revision. Hao
