On Sat, Apr 29, 2017 at 12:32:54AM +0200, Maciej S. Szmigiero wrote:
> 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.
Sorry for these confusing patches but it's too easy to fsck up
if you have to do things blind :-) Thank you, I appreciate this!
/Jarkko