Re: [PATCH v4.9 backport] tpm_tis: use default timeout value if chip reports it as zero

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/28/17 13:54, Jarkko Sakkinen wrote:
> On Wed, Apr 26, 2017 at 01:50:08PM +0200, Maciej S. Szmigiero wrote:
>> Jarkko,
>>
>> I've sent you my comments to this backport on 2017.04.25 00:01:40 +0200.
>>
>> Since it looks like you didn't get that message I will write them again
>> below, inline with the patch.
>>
>> Maciej
>>
>> On 04/26/17 12:41, Jarkko Sakkinen wrote:
>>> From: "Maciej S. Szmigiero" <mail@xxxxxxxxxxxxxxxxxxxxx>
>>>
>>> Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for
>>> TPM access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9)
>>> no longer works.  The initialization proceeds fine until we get and
>>> start using chip-reported timeouts - and the chip reports C and D
>>> timeouts of zero.
>>>
>>> It turns out that until commit 8e54caf407b98e ("tpm: Provide a generic
>>> means to override the chip returned timeouts") we had actually let
>>> default timeout values remain in this case, so let's bring back this
>>> behavior to make chips like Atmel 3203 work again.
>>>
>>> Use a common code that was introduced by that commit so a warning is
>>> printed in this case and /sys/class/tpm/tpm*/timeouts correctly says the
>>> timeouts aren't chip-original.
>>>
>>> Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM access")
>>> Cc: stable@xxxxxxxxxxxxxxx
>>> Signed-off-by: Maciej S. Szmigiero <mail@xxxxxxxxxxxxxxxxxxxxx>
>>> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
>>> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
>>> ---
>>> Backport of 1d70fe9d9c3a4 to v4.9
>>> PS. I was not able to test this. Tried to check that diff is the same.
>>>  drivers/char/tpm/tpm-interface.c | 54 ++++++++++++++++++++++++----------------
>>>  drivers/char/tpm/tpm_tis.c       |  2 +-
>>>  drivers/char/tpm/tpm_tis_core.c  |  6 ++---
>>>  drivers/char/tpm/tpm_tis_core.h  |  2 +-
>>>  4 files changed, 38 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
>>> index 3a9149cf0110..9788f839bb7c 100644
>>> --- a/drivers/char/tpm/tpm-interface.c
>>> +++ b/drivers/char/tpm/tpm-interface.c
>>> @@ -488,10 +488,10 @@ static int tpm_startup(struct tpm_chip *chip, __be16 startup_type)
>>>  
>>>  int tpm_get_timeouts(struct tpm_chip *chip)
>>>  {
>>> +	cap_t cap;
>>
>> This is not needed.
>>
>>>  	struct tpm_cmd_t tpm_cmd;
>>> -	unsigned long new_timeout[4];
>>> -	unsigned long old_timeout[4];
>>>  	struct duration_t *duration_cap;
>>> +	unsigned long timeout_old[4], timeout_chip[4], timeout_eff[4];
>>>  	ssize_t rc;
>>>  
>>>  	if (chip->flags & TPM_CHIP_FLAG_TPM2) {
>>> @@ -542,11 +542,15 @@ int tpm_get_timeouts(struct tpm_chip *chip)
>>>  	    != sizeof(tpm_cmd.header.out) + sizeof(u32) + 4 * sizeof(u32))
>>>  		return -EINVAL;
>>>  
>>> -	old_timeout[0] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.a);
>>> -	old_timeout[1] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.b);
>>> -	old_timeout[2] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.c);
>>> -	old_timeout[3] = be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.d);
>>> -	memcpy(new_timeout, old_timeout, sizeof(new_timeout));
>>> +	timeout_old[0] = jiffies_to_usecs(chip->timeout_a);
>>> +	timeout_old[1] = jiffies_to_usecs(chip->timeout_b);
>>> +	timeout_old[2] = jiffies_to_usecs(chip->timeout_c);
>>> +	timeout_old[3] = jiffies_to_usecs(chip->timeout_d);
>>> +	timeout_chip[0] = be32_to_cpu(cap.timeout.a);
>>> +	timeout_chip[1] = be32_to_cpu(cap.timeout.b);
>>> +	timeout_chip[2] = be32_to_cpu(cap.timeout.c);
>>> +	timeout_chip[3] = be32_to_cpu(cap.timeout.d);
>>
>> These last 4 lines should be "= be32_to_cpu(tpm_cmd.params.getcap_out.cap.timeout.X")
>> as in the removed ones.
> 
> Gah. The problem is that I do not have means to test this patch
> with HW where it occured. Can you send an updated version to
> stable as you have means to test it? Thank you.

Yes, I can do it but it might take a few days.

> /Jarkko

Maciej




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]