[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8700.1218793145@turing-police.cc.vt.edu>
Date: Fri, 15 Aug 2008 05:39:05 -0400
From: Valdis.Kletnieks@...edu
To: Marcin Obara <marcin_obara@...rs.sourceforge.net>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Marcel Selhorst <tpm@...horst.net>,
Kylene Jo Hall <kjhall@...ibm.com>,
tpmdd-devel@...ts.sourceforge.net
Subject: Re: [PATCH] 2.6.26-mmotm tpm-correct-tpm-timeouts-to-jiffies-conversion-d820-fix.patch
On Sat, 26 Jul 2008 20:27:33 BST, Marcin Obara said:
> Value in chip->vendor.duration[TPM_SHORT] is in jiffies not in milliseconds.
> (As I know it's not the same. Jiffy is in range 1-10 ms.)
> I know the result may be the same, but it is unclear.
I suppose I could have worded the comment block better - the intent was to
point out what the Broadcom chip returns, but by that point in the code
we're dealing with jiffies...
> Maybe... value should be compared (to 1000) before conversion?
Actually, that's probably a better idea, because my kernel is built with
HZ=1000 - usecs_to_jiffies will do something different than ==1 for HZ=100
or HZ=250 or other odd values.
> If after conversion, there should be something like this:
> if (chip->vendor.duration[TPM_SHORT] < (HZ/100)) /* less
> than 10ms ? */
> chip->vendor.duration[TPM_SHORT] = HZ;
That's another option as well, that does the right thing for various HZ values.
> What do you think?
Let me go cook up and test another iteration of the patch, will probably be
a few hours...
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists