This driver does not use any module parameters anymore,
so the inclusion of the header file can be removed.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
The I2C client driver is not supposed to modify the client's driver pointer,
this is handled by the I2C core.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
The 8119807 commit reintroduced a regression
(error: __ksymtab_tpm_dev_release causes a section type conflict) that was fixed by commit
cbb2ed4.
Fix it for good by adding the prototype to tpm.h so sparse doesn't
complain about it anymore.
Reported-by: Tony Camuso <tcamuso@redhat.com>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
IMA requires access to TPM_DIGEST_SIZE definition. This patch
moves the definition to <linux/tpm.h>.
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Add the missing platform_driver_unregister() before return
from init_tis() in the device register error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
If the TPM has already been sent a SaveState command before the driver
is loaded it may have problems sending that same command again later.
This issue is seen with the Chromebook Pixel due to a firmware bug in
the legacy mode boot path which is sending the SaveState command
before booting the kernel. More information is available at
http://crbug.com/203524
This change introduces a retry of the SaveState command in the suspend
path in order to work around this issue. A future firmware update
should fix this but this is also a trivial workaround in the driver
that has no effect on systems that do not show this problem.
When this does happen the TPM responds with a non-fatal TPM_RETRY code
that is defined in the specification:
The TPM is too busy to respond to the command immediately, but the
command could be resubmitted at a later time. The TPM MAY return
TPM_RETRY for any command at any time.
It can take several seconds before the TPM will respond again. I
measured a typical time between 3 and 4 seconds and the timeout is set
at a safe 5 seconds.
It is also possible to reproduce this with commands via /dev/tpm0.
The bug linked above has a python script attached which can be used to
test for this problem. I tested a variety of TPMs from Infineon,
Nuvoton, Atmel, and STMicro but was only able to reproduce this with
LPC and I2C TPMs from Infineon.
The TPM specification only loosely defines this behavior:
TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState:
The TPM MAY declare all preserved values invalid in response to any
command other than TPM_Init.
TCG PC Client BIOS Spec 1.21 section 8.3.1.
After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM
commands before transitioning to S3 without issuing another
TPM_SaveState command.
TCG PC Client TIS 1.21, section 4. Power Management:
The TPM_SaveState command allows a Static OS to indicate to the TPM
that the platform may enter a low power state where the TPM will be
required to enter into the D3 power state. The use of the term "may"
is significant in that there is no requirement for the platform to
actually enter the low power state after sending the TPM_SaveState
command. The software may, in fact, send subsequent commands after
sending the TPM_SaveState command.
Change-Id: I52b41e826412688e5b6c8ddd3bb16409939704e9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Kent Yoder indicated that the code might be a bit clearer with a comment
here, so this patch adds a small explanation of the code.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
As the subject says.
It's probably a good idea to have these fields populated.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
This driver adds support for Infineon's new SLB 9645 TT 1.2 I2C TPMs,
which supports clockstretching, combined reads and a bus speed of
up to 400khz. The device also has a new device id.
The driver works now also fine with device trees, so you can
instantiate your device by adding:
+ tpm {
+ compatible = "infineon,slb9645tt";
+ reg = <0x20>;
+ };
for SLB 9645 devices or
+ tpm {
+ compatible = "infineon,slb9635tt";
+ reg = <0x20>;
+ };
for SLB 9635 devices
to your device tree.
tpm_i2c_infineon is also retained as a compatible id as a fallback to
slb9635 protocol.
The driver was tested on Beaglebone.
Signed-off-by: Peter Huewe <peter.huewe@infineon.com>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Thanks to Julia Lawall for automating the conversion.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Peter Huewe <peter.huewe@infineon.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Ensure that the 'version' string includes a NULL terminator after its
copied out of the acpi table.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
We don't need a temporary variable just to store the return value which
gets return in the next statement.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Err is never read before it is assigned again -> remove the dead
assigment.
Found with clang static analyzer
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
With the HOTPLUG changes 3.8 this attribute is going away.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
We don't need to call memcpy for one byte, but assign it directly.
And to make the offset clearer we use the array syntax on the subsequent
call to memset to make the relationship clearer.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
The TIS specification (pg 47) says the valid bit must be set, but
the TPM will not set it until it has completed its internal startup.
The driver checks that the valid bit is set during request_locality,
but it issues a TPM_ACCESS_REQUEST_USE without validating the
valid bit is set.
Some TPMs will ignore the TPM_ACCESS_REQUEST_USE, until valid is
set which causes the request_locality to timeout, which breaks the
driver attach.
Wait one timeout unit for valid to assert. If valid does not assert
then assume -ENODEV.
Seen on embedded with a:
1.2 TPM (device-id 0x3204, rev-id 64)
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
On one of my machines the cancellation of TPM commands does not work.
The reason is that by writing into sysfs 'cancel' the tpm_tis_ready
call causes the status flag TPM_STS_VALID to be set in the statusregister.
However, the TIS driver seems to wait for TPM_STS_COMMAND_READY.
Once a 2nd time sysfs 'cancel' is written to, the TPM_STS_COMMAND_READY flag
also gets set, resulting in TPM_STS_VALID|TPM_STS_COMMAND_READY to be
read from the status register.
This patch now converts req_canceled into a function to enable more complex
comparisons against possible cancellation status codes.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
We've been testing an alternative TPM for our embedded products and
found random kernel boot failures due to time outs after the continue
self test command.
This was happening randomly, and has been *very* hard to track down, but
it
looks like with this chip there is some kind of race with the
tpm_tis_status()
check of TPM_STS_COMMAND_READY. If things get there 'too fast' then
it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes
somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY.
Adding some delay after tpm_continue_selftest() makes things reliably
hit the failure path, otherwise it is a crapshot.
The spec says it should be returning TPM_WARN_DOING_SELFTEST, not
holding
off on ready..
Boot log during this event looks like this:
tpm_tis 70030000.tpm_tis: 1.2 TPM (device-id 0x3204, rev-id 64)
tpm_tis 70030000.tpm_tis: Issuing TPM_STARTUP
tpm_tis 70030000.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 70030000.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
tpm_tis 70030000.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 70030000.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
tpm_tis 70030000.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 70030000.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
tpm_tis 70030000.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 70030000.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
The other TPM vendor we use doesn't show this wonky behaviour:
tpm_tis 70030000.tpm_tis: 1.2 TPM (device-id 0xFE, rev-id 70)
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
