When probing the device in tpm_tis_init the call request_locality
uses timeout_a, which wasn't being initalized until after
request_locality. This results in request_locality falsely timing
out if the chip is still starting. Move the initialization to before
request_locality.
This probably only matters for embedded cases (ie mine), a BIOS likely
gets the TPM into a state where this code path isn't necessary.
Signed-off-by: Jason Gunthorpe <[email protected]>
---
drivers/char/tpm/tpm_tis.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 241b5ae..c1e5ab8 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -450,6 +450,12 @@ static int tpm_tis_init(struct device *dev, u32 start,
goto out_err;
}
+ /* Default timeouts */
+ chip->vendor.timeout_a = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
+ chip->vendor.timeout_b = msecs_to_jiffies(TIS_LONG_TIMEOUT);
+ chip->vendor.timeout_c = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
+ chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
+
if (request_locality(chip, 0) != 0) {
rc = -ENODEV;
goto out_err;
@@ -457,12 +463,6 @@ static int tpm_tis_init(struct device *dev, u32 start,
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
- /* Default timeouts */
- chip->vendor.timeout_a = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
- chip->vendor.timeout_b = msecs_to_jiffies(TIS_LONG_TIMEOUT);
- chip->vendor.timeout_c = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
- chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
-
dev_info(dev,
"1.2 TPM (device-id 0x%X, rev-id %d)\n",
vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
--
1.5.4.2
Andy Isaacson sent this a while ago in a patchset, I think I lost track
of it in the middle of the other patches, sorry. In any case, ACK.
http://marc.info/?l=linux-kernel&m=124650185023490&w=2
Thanks,
Rajiv
On Wed, 2009-09-09 at 17:22 -0600, Jason Gunthorpe wrote:
> When probing the device in tpm_tis_init the call request_locality
> uses timeout_a, which wasn't being initalized until after
> request_locality. This results in request_locality falsely timing
> out if the chip is still starting. Move the initialization to before
> request_locality.
>
> This probably only matters for embedded cases (ie mine), a BIOS likely
> gets the TPM into a state where this code path isn't necessary.
>
> Signed-off-by: Jason Gunthorpe <[email protected]>
> ---
> drivers/char/tpm/tpm_tis.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index 241b5ae..c1e5ab8 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -450,6 +450,12 @@ static int tpm_tis_init(struct device *dev, u32 start,
> goto out_err;
> }
>
> + /* Default timeouts */
> + chip->vendor.timeout_a = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> + chip->vendor.timeout_b = msecs_to_jiffies(TIS_LONG_TIMEOUT);
> + chip->vendor.timeout_c = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> + chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> +
> if (request_locality(chip, 0) != 0) {
> rc = -ENODEV;
> goto out_err;
> @@ -457,12 +463,6 @@ static int tpm_tis_init(struct device *dev, u32 start,
>
> vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
>
> - /* Default timeouts */
> - chip->vendor.timeout_a = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> - chip->vendor.timeout_b = msecs_to_jiffies(TIS_LONG_TIMEOUT);
> - chip->vendor.timeout_c = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> - chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> -
> dev_info(dev,
> "1.2 TPM (device-id 0x%X, rev-id %d)\n",
> vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
On Wed, 9 Sep 2009, Rajiv Andrade wrote:
> Andy Isaacson sent this a while ago in a patchset, I think I lost track
> of it in the middle of the other patches, sorry. In any case, ACK.
>
> http://marc.info/?l=linux-kernel&m=124650185023490&w=2
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
This will be pushed to Linus within the next day as part of the merge for
2.6.32, and I'm guessing needs to be in -stable.
--
James Morris
<[email protected]>
On Thu, Sep 10, 2009 at 07:21:33PM +1000, James Morris wrote:
> On Wed, 9 Sep 2009, Rajiv Andrade wrote:
> > Andy Isaacson sent this a while ago in a patchset, I think I lost track
> > of it in the middle of the other patches, sorry. In any case, ACK.
Thanks Rajiv
> This will be pushed to Linus within the next day as part of the merge for
> 2.6.32, and I'm guessing needs to be in -stable.
Thanks - as for -stable I'm expecting not many people are affected by
this, but I doubt it hurts anything. This is actually fixing a
regression introduced by 05a462afe80553550bc77afc724ce60b42ad587e if
that matters.
Jason