On Mon, May 14, 2018 at 01:46:00PM +0300, Jarkko Sakkinen wrote:
> On Mon, May 07, 2018 at 12:07:32PM -0400, Nayna Jain wrote:
> > tpm_try_transmit currently checks TPM status every 5 msecs between
> > send and recv. It does so in a loop for the maximum timeout as defined
> > in the TPM Interface S
On Mon, May 07, 2018 at 12:07:32PM -0400, Nayna Jain wrote:
> tpm_try_transmit currently checks TPM status every 5 msecs between
> send and recv. It does so in a loop for the maximum timeout as defined
> in the TPM Interface Specification. However, the TPM may return before
> 5 msecs. Thus the poll
On 05/10/2018 06:11 PM, Nayna Jain wrote:
On 05/08/2018 10:04 PM, J Freyensee wrote:
do {
- tpm_msleep(TPM_POLL_SLEEP);
+ tpm_msleep(TPM_TIMEOUT_POLL);
I'm just curious why it was decided to still use tpm_msleep() here
instead of usleep_range() which was u
On 05/08/2018 10:04 PM, J Freyensee wrote:
do {
- tpm_msleep(TPM_POLL_SLEEP);
+ tpm_msleep(TPM_TIMEOUT_POLL);
I'm just curious why it was decided to still use tpm_msleep() here
instead of usleep_range() which was used in the 2nd patch.
TPM_TIMEOUT_POLL is i
do {
- tpm_msleep(TPM_POLL_SLEEP);
+ tpm_msleep(TPM_TIMEOUT_POLL);
I'm just curious why it was decided to still use tpm_msleep() here
instead of usleep_range() which was used in the 2nd patch.
Otherwise,
Acked-by: Jay Freyensee
5 matches
Mail list logo