kernel/git/stable/linux.git/drivers/char/tpm/tpm.c, branch master

tpm: Rename tpm.c to tpm-interface.c

2013-10-22T17:42:51+00:00

This is preparation for making the tpm module multi-file. kbuild does not like having a .c file with the same name as a module. We wish to keep the tpm module name so that userspace doesn't see this change. tpm-interface.c is chosen because the next several commits in the series migrate items into tpm-sysfs.c, tpm-dev.c and tpm-class.c. All that will be left is tpm command processing and interfacing code. Signed-off-by: Jason Gunthorpe

tpm: cleanup checkpatch warnings

2013-10-22T17:42:48+00:00

before we rename the file it might be a good idea to cleanup the long persisting checkpatch warnings. Since everything is really trivial, splitting the patch up would only result in noise. For the interested reader - here the checkpatch warnings: (regrouped for easer readability) ERROR: trailing whitespace + * Specifications at www.trustedcomputinggroup.org^I $ + * $ +^I/* $ +^I parameters (RSA 12->bytes: keybit, #primes, expbit) $ WARNING: unnecessary whitespace before a quoted newline + "invalid count value %x %zx \n", count, bufsiz); ERROR: do not use assignment in if condition + if ((rc = chip->vendor.send(chip, (u8 *) buf, count)) < 0) { ERROR: space required after that ',' (ctx:VxV) + len = tpm_transmit(chip,(u8 *) cmd, len); ^ ERROR: "foo * bar" should be "foo *bar" +ssize_t tpm_show_enabled(struct device * dev, struct device_attribute * attr, +ssize_t tpm_show_enabled(struct device * dev, struct device_attribute * attr, +ssize_t tpm_show_active(struct device * dev, struct device_attribute * attr, +ssize_t tpm_show_active(struct device * dev, struct device_attribute * attr, +ssize_t tpm_show_owned(struct device * dev, struct device_attribute * attr, +ssize_t tpm_show_owned(struct device * dev, struct device_attribute * attr, +ssize_t tpm_show_temp_deactivated(struct device * dev, + struct device_attribute * attr, char *buf) WARNING: please, no space before tabs + * @chip_num: ^Itpm idx # or ANY$ + * @res_buf: ^ITPM_PCR value$ + * ^I^Isize of res_buf is 20 bytes (or NULL if you don't care)$ + * @chip_num: ^Itpm idx # or AN&$ + * @hash: ^Ihash value used to extend pcr value$ ERROR: code indent should use tabs where possible +^I TPM_ORD_CONTINUE_SELFTEST);$ WARNING: line over 80 characters +static bool wait_for_tpm_stat_cond(struct tpm_chip *chip, u8 mask, bool check_cancel, ERROR: trailing whitespace + * Called from tpm_.c probe function only for devices $ total: 16 errors, 7 warnings, 1554 lines checked Signed-off-by: Peter Huewe

tpm: Remove tpm_show_caps_1_2

2013-10-22T17:42:41+00:00

The version of the TPM should not depend on the bus it is connected through. 1.1, 1.2 and soon 2.0 TPMS will be all be able to use the same bus interfaces. Make tpm_show_caps try the 1.2 capability first. If that fails then fall back to the 1.1 capability. This effectively auto-detects what interface the TPM supports at run-time. Signed-off-by: Jason Gunthorpe Reviewed-by: Joel Schopp Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe

tpm: Use container_of to locate the tpm_chip in tpm_open

2013-10-22T17:42:31+00:00

misc_open sets the file->private_date to the misc_dev when calling open. We can use container_of to go from the misc_dev back to the tpm_chip. Future clean ups will move tpm_open into a new file and this change means we do not have to export the tpm_chip list. Signed-off-by: Jason Gunthorpe Reviewed-by: Joel Schopp Reviewed-by: Peter Huewe Acked-by: Ashley Lai Signed-off-by: Peter Huewe

tpm: Store devname in the tpm_chip

2013-10-22T17:42:28+00:00

Just put the memory directly in the chip structure, rather than in a 2nd dedicated kmalloc. Signed-off-by: Jason Gunthorpe Reviewed-by: Joel Schopp Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Acked-by: Ashley Lai

tpm: fix regression caused by section type conflict of tpm_dev_release() in ppc builds

2013-05-27T20:09:09+00:00

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 Signed-off-by: Peter Huewe

TPM: Retry SaveState command in suspend path

2013-04-17T14:31:32+00:00

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 Signed-off-by: Kent Yoder

tpm: Fix cancellation of TPM commands (interrupt mode)

2013-02-05T15:38:24+00:00

Support cancellation of TPM commands when driver is used in interrupt mode. Signed-off-by: Stefan Berger Signed-off-by: Kent Yoder

tpm: Fix cancellation of TPM commands (polling mode)

2013-02-05T15:38:24+00:00

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 Signed-off-by: Kent Yoder

TPM: Work around buggy TPMs that block during continue self test

2013-02-05T15:38:24+00:00

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 Signed-off-by: Kent Yoder