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
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
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
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
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
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
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
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
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
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
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 polling interval for each iteration can be reduced,
which improves
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 polling interval for each iteration can be reduced,
which improves
12 matches
Mail list logo
