]> git.proxmox.com Git - mirror_ubuntu-kernels.git/commit
tpm_tis_spi: Don't send anything during flow control
authorDouglas Anderson <dianders@chromium.org>
Thu, 28 May 2020 22:19:30 +0000 (15:19 -0700)
committerJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Thu, 2 Jul 2020 14:48:59 +0000 (17:48 +0300)
commiteac9347d932b96c09f089ac0673ebe588983e59b
tree118ee9b2a571c853a87d497bae52336534831076
parent7862840219058436b80029a0263fd1ef065fb1b3
tpm_tis_spi: Don't send anything during flow control

During flow control we are just reading from the TPM, yet our spi_xfer
has the tx_buf and rx_buf both non-NULL which means we're requesting a
full duplex transfer.

SPI is always somewhat of a full duplex protocol anyway and in theory
the other side shouldn't really be looking at what we're sending it
during flow control, but it's still a bit ugly to be sending some
"random" data when we shouldn't.

The default tpm_tis_spi_flow_control() tries to address this by
setting 'phy->iobuf[0] = 0'.  This partially avoids the problem of
sending "random" data, but since our tx_buf and rx_buf both point to
the same place I believe there is the potential of us sending the
TPM's previous byte back to it if we hit the retry loop.

Another flow control implementation, cr50_spi_flow_control(), doesn't
address this at all.

Let's clean this up and just make the tx_buf NULL before we call
flow_control().  Not only does this ensure that we're not sending any
"random" bytes but it also possibly could make the SPI controller
behave in a slightly more optimal way.

NOTE: no actual observed problems are fixed by this patch--it's was
just made based on code inspection.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
drivers/char/tpm/tpm_tis_spi_main.c