Adds plumbing required for drivers based on tpm_tis to set hwrng quality.
Signed-off-by: NLouis Collard <louiscollard@chromium.org>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The TPM burstcount and status commands are supposed to return very
quickly [2][3]. This patch further reduces the TPM poll sleep time to usecs
in get_burstcount() and wait_for_tpm_stat() by calling usleep_range()
directly.

After this change, performance on a system[1] with a TPM 1.2 with an 8 byte
burstcount for 1000 extends improved from ~10.7 sec to ~7 sec.

[1] All tests are performed on an x86 based, locked down, single purpose
closed system. It has Infineon TPM 1.2 using LPC Bus.

[2] From the TCG Specification "TCG PC Client Specific TPM Interface
Specification (TIS), Family 1.2":

"NOTE : It takes roughly 330 ns per byte transfer on LPC. 256 bytes would
take 84 us, which is a long time to stall the CPU. Chipsets may not be
designed to post this much data to LPC; therefore, the CPU itself is
stalled for much of this time. Sending 1 kB would take 350 μs. Therefore,
even if the TPM_STS_x.burstCount field is a high value, software SHOULD
be interruptible during this period."

[3] From the TCG Specification 2.0, "TCG PC Client Platform TPM Profile
(PTP) Specification":

"It takes roughly 330 ns per byte transfer on LPC. 256 bytes would take
84 us. Chipsets may not be designed to post this much data to LPC;
therefore, the CPU itself is stalled for much of this time. Sending 1 kB
would take 350 us. Therefore, even if the TPM_STS_x.burstCount field is a
high value, software should be interruptible during this period. For SPI,
assuming 20MHz clock and 64-byte transfers, it would take about 120 usec
to move 256B of data. Sending 1kB would take about 500 usec. If the
transactions are done using 4 bytes at a time, then it would take about
1 msec. to transfer 1kB of data."
Signed-off-by: NNayna Jain <nayna@linux.vnet.ibm.com>
Reviewed-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Acked-by: NJay Freyensee <why2jjj.linux@gmail.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

tpm_try_transmit currently checks TPM status every 5 msecs between
send and recv. It does so in a loop for the maximum timeout as defined
in the TPM Interface Specification. However, the TPM may return before
5 msecs. Thus the polling interval for each iteration can be reduced,
which improves overall performance. This patch changes the polling sleep
time from 5 msecs to 1 msec.

Additionally, this patch renames TPM_POLL_SLEEP to TPM_TIMEOUT_POLL and
moves it to tpm.h as an enum value.

After this change, performance on a system[1] with a TPM 1.2 with an 8 byte
burstcount for 1000 extends improved from ~14 sec to ~10.7 sec.

[1] All tests are performed on an x86 based, locked down, single purpose
closed system. It has Infineon TPM 1.2 using LPC Bus.
Signed-off-by: NNayna Jain <nayna@linux.vnet.ibm.com>
Acked-by: NJay Freyensee <why2jjj.linux@gmail.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

For certain tpm chips releasing locality can take long enough that a
subsequent call to request_locality will see the locality as being active
when the access register is read in check_locality. So check that the
locality has been released before returning from release_locality.

Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Reported-by: NLaurent Bigonville <bigon@debian.org>
Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com>
Tested-by: NLaurent Bigonville <bigon@debian.org>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The correct sequence is to first request locality and only after
that perform cmd_ready handshake, otherwise the hardware will drop
the subsequent message as from the device point of view the cmd_ready
handshake wasn't performed. Symmetrically locality has to be relinquished
only after going idle handshake has completed, this requires that
go_idle has to poll for the completion and as well locality
relinquish has to poll for completion so it is not overridden
in back to back commands flow.

Two wrapper functions are added (request_locality relinquish_locality)
to simplify the error handling.

The issue is only visible on devices that support multiple localities.

Fixes: 877c57d0 ("tpm_crb: request and relinquish locality 0")
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.
Signed-off-by: NJeremy Boone <jeremy.boone@nccgroup.trust>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJames Morris <james.morris@microsoft.com>

Commit 5e572cab ("tpm: Enable CLKRUN protocol for Braswell systems")
added logic in the TPM TIS driver to disable the Low Pin Count CLKRUN
signal during TPM transactions.

Unfortunately this breaks other devices that are attached to the LPC bus
like for example PS/2 mouse and keyboards.

One flaw with the logic is that it assumes that the CLKRUN is always
enabled, and so it unconditionally enables it after a TPM transaction.

But it could be that the CLKRUN# signal was already disabled in the LPC
bus and so after the driver probes, CLKRUN_EN will remain enabled which
may break other devices that are attached to the LPC bus but don't have
support for the CLKRUN protocol.

Fixes: 5e572cab ("tpm: Enable CLKRUN protocol for Braswell systems")
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Tested-by: NJames Ettle <james@ettle.org.uk>
Tested-by: NJeffery Miller <jmiller@neverware.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The coding style says "use just one data declaration per line (no commas
for multiple data declarations)" so follow this convention.
Suggested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

This flag is only used to warn if CLKRUN_EN wasn't disabled on Braswell
systems, but the only way this can happen is if the code is not correct.

So it's an unnecessary check that just makes the code harder to read.
Suggested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Commit 5e572cab ("tpm: Enable CLKRUN protocol for Braswell
systems") disabled CLKRUN protocol during TPM transactions and re-enabled
once the transaction is completed. But there were still some corner cases
observed where, reading of TPM header failed for savestate command
while going to suspend, which resulted in suspend failure.
To fix this issue keep the CLKRUN protocol disabled for the entire
duration of a single TPM command and not disabling and re-enabling
again for every TPM transaction. For the other TPM accesses outside
TPM command flow, add a higher level of disabling and re-enabling
the CLKRUN protocol, instead of doing for every TPM transaction.

Fixes: 5e572cab ("tpm: Enable CLKRUN protocol for Braswell systems")
Signed-off-by: NAzhar Shaikh <azhar.shaikh@intel.com>
Reviewed-by: NJarkko Sakkinen  <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen  <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen  <jarkko.sakkinen@linux.intel.com>

Move static variable ilb_base_addr to tpm_tis_data.

Cc: stable@vger.kernel.org
Signed-off-by: NAzhar Shaikh <azhar.shaikh@intel.com>
Reviewed-by: NJarkko Sakkinen  <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen  <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen  <jarkko.sakkinen@linux.intel.com>

The existing wait_for_tpm_stat() polls for the chip status after
5msec sleep. As per TCG ddwg input, it is expected that tpm might
return status in few usec. So, reducing the delay in polling to
1msec.
Similarly, get_burstcount() function sleeps for 5msec before
retrying for next query to burstcount in a loop. If it takes
lesser time for TPM to return, this 5msec delay is longer than
necessary.

After this change, performance on a TPM 1.2 with an 8 byte
burstcount for 1000 extends improved from ~14sec to ~9sec.
Signed-off-by: NNayna Jain <nayna@linux.vnet.ibm.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The function wait_for_tpm_stat() is currently defined in
tpm-interface file. It is a hardware specific function used
only by tpm_tis and xen-tpmfront, so it is removed from
tpm-interface.c and defined in respective driver files.
Suggested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NNayna Jain <nayna@linux.vnet.ibm.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Making cmd_getticks 'const' introduced a couple of harmless warnings:

drivers/char/tpm/tpm_tis_core.c: In function 'probe_itpm':
drivers/char/tpm/tpm_tis_core.c:469:31: error: passing argument 2 of 'tpm_tis_send_data' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  rc = tpm_tis_send_data(chip, cmd_getticks, len);
drivers/char/tpm/tpm_tis_core.c:477:31: error: passing argument 2 of 'tpm_tis_send_data' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  rc = tpm_tis_send_data(chip, cmd_getticks, len);
drivers/char/tpm/tpm_tis_core.c:255:12: note: expected 'u8 * {aka unsigned char *}' but argument is of type 'const u8 * {aka const unsigned char *}'
 static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)

This changes the related functions to all take 'const' pointers
so that gcc can see this as being correct. I had to slightly
modify the logic around tpm_tis_spi_transfer() for this to work
without introducing ugly casts.

Cc: stable@vger.kernel.org
Fixes: 5e35bd8e06b9 ("tpm_tis: make array cmd_getticks static const to shink object code size")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Don't populate array cmd_getticks on the stack, instead make it static
const.  Makes the object code smaller by over 160 bytes:

Before:
   text	   data	    bss	    dec	    hex	filename
  18813	   3152	    128	  22093	   564d	drivers/char/tpm/tpm_tis_core.o

After:
   text	   data	    bss	    dec	    hex	filename
  18554	   3248	    128	  21930	   55aa	drivers/char/tpm/tpm_tis_core.o

Cc: stable@vger.kernel.org
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The patch simply replaces all msleep function calls with usleep_range calls
in the generic drivers.

Tested with an Infineon TPM 1.2, using the generic tpm-tis module, for a
thousand PCR extends, we see results going from 1m57s unpatched to 40s
with the new patch. We obtain similar results when using the original and
patched tpm_infineon driver, which is also part of the patch.
Similarly with a STM TPM 2.0, using the CRB driver, it takes about 20ms per
extend unpatched and around 7ms with the new patch.

Note that the PCR consistency is untouched with this patch, each TPM has
been tested with 10 million extends and the aggregated PCR value is
continuously verified to be correct.

As an extension of this work, this could potentially and easily be applied
to other vendor's drivers. Still, these changes are not included in the
proposed patch as they are untested.
Signed-off-by: NHamza Attak <hamza@hpe.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>

This patch converts tpm_tis to use of the new tpm class ops
request_locality, and relinquish_locality.

With the move to using the callbacks, release_locality is changed so
that we now release the locality even if there is no request pending.

This required some changes to the tpm_tis_core_init code path to
make sure locality is requested when needed:

  - tpm2_probe code path will end up calling request/release through
    callbacks, so request_locality prior to tpm2_probe not needed.

  - probe_itpm makes calls to tpm_tis_send_data which no longer calls
    request_locality, so add request_locality prior to tpm_tis_send_data
    calls. Also drop release_locality call in middleof probe_itpm, and
    keep locality until release_locality called at end of probe_itpm.

Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Marcel Selhorst <tpmdd@selhorst.net>
Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Since check_locality is checking to see if a certain
locality is active, return true if active otherwise
return false.

Cc: Christophe Ricard <christophe.ricard@gmail.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Marcel Selhorst <tpmdd@selhorst.net>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

TIS v1.3 for TPM 1.2 and PTP for TPM 2.0 disagree about which timeout
value applies to reading a valid burstcount. It is TIMEOUT_D according to
TIS, but TIMEOUT_A according to PTP, so choose the appropriate value
depending on whether we deal with a TPM 1.2 or a TPM 2.0.

This is important since according to the PTP TIMEOUT_D is much smaller
than TIMEOUT_A. So the previous implementation could run into timeouts
with a TPM 2.0, even though the TPM was behaving perfectly fine.

During tpm2_probe TIMEOUT_D will be used even with a TPM 2.0, because
TPM_CHIP_FLAG_TPM2 is not yet set. This is fine, since the timeout values
will only be changed afterwards by tpm_get_timeouts. Until then
TIS_TIMEOUT_D_MAX applies, which is large enough.

Cc: stable@vger.kernel.org
Fixes: aec04cbd ("tpm: TPM 2.0 FIFO Interface")
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

probe_itpm() function is supposed to send command without an itpm flag set
and if this fails to repeat it, this time with the itpm flag set.

However, commit 41a5e1cf ("tpm/tpm_tis: Split tpm_tis driver into a
core and TCG TIS compliant phy") moved the itpm flag from an "itpm"
variable to a TPM_TIS_ITPM_POSSIBLE chip flag, so setting the
(now function-local) itpm variable no longer had any effect.

Finally, this function-local itpm variable was removed by
commit 56af3221 ("tpm/tpm_tis: remove unused itpm variable")

Tested only on non-iTPM TIS TPM.
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Make sure that we have not received less bytes than what is indicated
in the header of the TPM response. Also, check the number of bytes in
the response before accessing its data.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkine@linux.intel.com>

Since commit 1107d065 ("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 8e54caf4 ("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: 1107d065 ("tpm_tis: Introduce intermediate layer for TPM access")
Cc: stable@vger.kernel.org
Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The tis driver does a tpm_get_timeouts out side of tpm_chip_register,
and tpm_get_timeouts can print a message, resulting in two prints, eg:

 tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 10000->750000us B 10000->2000000us C 10000->750000us D 10000->750000us

Keep track and prevent tpm_get_timeouts from running a second time, and
clarify the purpose of the call in tpm_tis_core to only be connected to
irq testing.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

If the TPM we're connecting to uses a static burst count, it will report
a burst count of zero throughout the response read. However, get_burstcount
assumes that a response of zero indicates that the TPM is not ready to
receive more data. In this case, it returns a negative error code, which
is passed on to tpm_tis_{write,read}_bytes as a u16, causing
them to read/write far too many bytes.

This patch checks for negative return codes and bails out from recv_data
and tpm_tis_send_data.

Cc: stable@vger.kernel.org
Fixes: 1107d065 (tpm_tis: Introduce intermediate layer for TPM access)
Signed-off-by: NJosh Zimmerman <joshz@google.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

In some weird cases it might be possible that the TPM does not set
STS.VALID within the given timeout time (or ever) but sets STS.EXPECT
(STS=0x0C) In this case the driver gets stuck in the while loop of
tpm_tis_send_data and loops endlessly.

Checking the return value of wait_for_tpm_stat fixes this and the driver
bails out correctly.  While at it fixing all other users since if the
TPM does not manage to set STS.VALID within the reasonable timeframe
something is definitely wrong and the driver should react correctly.
Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Fixes the warning:
drivers/char/tpm/tpm_tis_core.c:443:7: warning: variable ‘itpm’ set but
not used [-Wunused-but-set-variable]
  bool itpm;
       ^~~~
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Acked-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Since tpm_gen_interrupt() is only used in tpm_tis_core.c this commit
replaces it with an internal tpm_tis_gen_interrupt(). The semantics
also changed in a way that on a system error the driver initialization
is failed.
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>

The TCG standard startup sequence (get timeouts, tpm startup, etc) for
TPM and TPM2 chips is being open coded in many drivers, move it into
the core code.

tpm_tis and tpm_crb are used as the basis for the core code
implementation and the easy drivers are converted. In the process
several small drivers bugs relating to error handling this flow
are fixed.

For now the flag TPM_OPS_AUTO_STARTUP is optional to allow a staged
driver roll out, but ultimately all drivers should use this flow and
the flag removed. Some drivers still do not implement the startup
sequence at all and will need to be tested with it enabled.
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Tested-by: NAndrew Zamansky <andrew.zamansky@nuvoton.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Some chips incorrectly support partial reads from TPM_STS register
at non-zero offsets. Read the entire 32-bits register instead of
making two 8-bit reads to support such devices and reduce the number
of bus transactions when obtaining the burstcount from TPM_STS.

Fixes: 27084efe ("tpm: driver for next generation TPM chips")
Signed-off-by: NAndrey Pronin <apronin@chromium.org>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

tpm_tis_core was missing conversion from msec when assigning max
timeouts from constants.

Fixes: aec04cbd ("tpm: TPM 2.0 FIFO Interface")
Signed-off-by: NAndrey Pronin <apronin@chromium.org>
Reviewed-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

To avoid code duplication between the old tpm_tis and the new and future
native tcg tis driver(ie: spi, i2c...), the tpm_tis driver was reworked,
so that all common logic is extracted and can be reused from all drivers.

The core methods can also be used from other TIS like drivers.

itpm workaround is now managed with a specific tis flag
TPM_TIS_ITPM_POSSIBLE.

This commit is based on the initial work by Peter Huewe.
Signed-off-by: NPeter Huewe <peter.huewe@infineon.com>
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

This splits tpm_tis in a high-level protocol part and a low-level interface
for the actual TPM communication. The low-level interface can then be
implemented by additional drivers to provide access to TPMs using other
mechanisms, for example native I2C or SPI transfers, while still reusing
the same TIS protocol implementation.

Though the ioread/iowrite calls cannot fail, other implementations of this
interface might want to return error codes if their communication fails.

This follows the usual pattern of negative values representing errors and
zero representing success. Positive values are not used (yet).

Errors are passed back to the caller if possible. If the interface of a
function does not allow that, it tries to do the most sensible thing it
can, but this might also mean ignoring the error in this instance.

This commit is based on the initial work by Peter Huewe.
Signed-off-by: NAlexander Steffen <Alexander.Steffen@infineon.com>
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Split priv_data structure in common and phy specific structures. This will
allow in future patches to reuse the same tis logic on top of new phy such
as spi and i2c. Ultimately, other drivers may reuse this tis logic.
(e.g: st33zp24...)

iobase field is specific to TPM addressed on 0xFED4xxxx on LPC/SPI bus.

This commit is based on the initial work by Peter Huewe.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

The devm for the IRQ was placed on the chip, not the pdev. This can
cause the irq to be still callable after the pdev has been cleaned up
(eg priv kfree'd).

Found by CONFIG_DEBUG_SHIRQ=y
Reported-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Fixes: 233a065e0cd0 ("tpm: Get rid of chip->pdev")
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Tested-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Remove useless priv field in struct tpm_vendor_specific and take benefit
of chip->dev.driver_data.  As priv is the latest field available in
struct tpm_vendor_specific, remove any reference to that structure.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Move tpm_vendor_specific data related to TCG PTP specification to tpm_chip.

Move all fields directly linked with well known TCG concepts and used in
TPM drivers (tpm_i2c_atmel, tpm_i2c_infineon, tpm_i2c_nuvoton, tpm_tis
and xen-tpmfront) as well as in TPM core files (tpm-sysfs, tpm-interface
and tpm2-cmd) in tpm_chip.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Dropped the field 'locality' from struct tpm_vendor_specific migrated it to
the private structures of st33zp24, tpm_i2c_infineon and tpm_tis.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Dropped the field 'read_queue' from struct tpm_vendor_specific and make it
available to the various private structures in the drivers.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Dropped the field 'irq' from struct tpm_vendor_specific and make it
available to the various private structures in the drivers using irqs.

A dedicated flag TPM_CHIP_FLAG_IRQ is added for the upper layers.

In st33zp24, struct st33zp24_dev declaration is moved to st33zp24.h in
order to make accessible irq from other phy's(i2c, spi).

In tpm_i2c_nuvoton, chip->vendor.priv is not directly allocated. We can
access irq field from priv_data in a cleaner way.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

Dropped the field 'iobase' from struct tpm_vendor_specific and migrated
it to the private structures of tpm_atmel and tpm_tis.
Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com>
Reviewed-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>