mbox series

[V8,0/3] Tegra TPM driver with HW flow control

Message ID 20230302041804.24718-1-kyarlagadda@nvidia.com
Headers
Series Tegra TPM driver with HW flow control |

Message

Krishna Yarlagadda March 2, 2023, 4:18 a.m. UTC 
  TPM devices may insert wait state on last clock cycle of ADDR phase.
For SPI controllers that support full-duplex transfers, this can be
detected using software by reading the MISO line. For SPI controllers
that only support half-duplex transfers, such as the Tegra QSPI, it is
not possible to detect the wait signal from software. The QSPI
controller in Tegra234 and Tegra241 implement hardware detection of the
wait signal which can be enabled in the controller for TPM devices.

Add HW flow control in TIS driver and a flag in SPI data to indicate
wait detection is required in HW. SPI controller driver determines if
this is supported. Add HW detection in Tegra QSPI controller.

Updates in this patch set 
 - Tegra QSPI identifies itself as half duplex.
 - TPM TIS SPI driver skips flow control for half duplex and send
   transfers in single message for controller to handle it.
 - TPM device identifies as TPM device for controller to detect and
   enable HW TPM wait poll feature.

Verified with a TPM device on Tegra241 ref board using TPM2 tools.

V8:
 - fix compile warning.
V7:
 - updated patch description.
 - TPM flag set in probe.
 - minor comments.
V6:
 - Fix typo in chip name Tegra234.
 - Debug logs change skipped to be sent later.
 - Consistent usage of soc flag.
V5:
 - No SPI bus locking.
V4:
 - Split api change to different patch.
 - Describe TPM HW flow control.
V3:
 - Use SPI device mode flag and SPI controller flags.
 - Drop usage of device tree flags.
 - Generic TPM half duplex controller handling.
 - HW & SW flow control for TPM. Drop additional driver.
V2:
 - Fix dt schema errors.

Krishna Yarlagadda (3):
  spi: Add TPM HW flow flag
  tpm_tis-spi: Add hardware wait polling
  spi: tegra210-quad: Enable TPM wait polling

 drivers/char/tpm/tpm_tis_spi_main.c | 95 ++++++++++++++++++++++++++++-
 drivers/spi/spi-tegra210-quad.c     | 14 +++++
 include/linux/spi/spi.h             | 16 ++++-
 3 files changed, 120 insertions(+), 5 deletions(-)

Comments

Krishna Yarlagadda March 23, 2023, 11:57 a.m. UTC | #1 
> -----Original Message-----
> From: Hillf Danton <hdanton@sina.com>
> Sent: 19 March 2023 19:58
> To: Krishna Yarlagadda <kyarlagadda@nvidia.com>
> Cc: robh+dt@kernel.org; broonie@kernel.org; peterhuewe@gmx.de;
> jgg@ziepe.ca; jarkko@kernel.org; krzysztof.kozlowski+dt@linaro.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [Patch V8 2/3] tpm_tis-spi: Add hardware wait polling
> 
> External email: Use caution opening links or attachments
> 
> 
> On 2 Mar 2023 09:48:03 +0530 Krishna Yarlagadda <kyarlagadda@nvidia.com>
> > +static int tpm_tis_spi_hw_flow_transfer(struct tpm_tis_data *data,
> > +                                     u32 addr, u16 len, u8 *in,
> > +                                     const u8 *out)
> > +{
> > +     struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data);
> > +     struct spi_transfer spi_xfer[3];
> > +     struct spi_message m;
> > +     u8 transfer_len;
> > +     int ret;
> > +
> > +     while (len) {
> > +             transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE);
> > +
> > +             spi_message_init(&m);
> > +             phy->iobuf[0] = (in ? 0x80 : 0) | (transfer_len - 1);
> > +             phy->iobuf[1] = 0xd4;
> > +             phy->iobuf[2] = addr >> 8;
> > +             phy->iobuf[3] = addr;
> > +
> > +             memset(&spi_xfer, 0, sizeof(spi_xfer));
> > +
> > +             spi_xfer[0].tx_buf = phy->iobuf;
> > +             spi_xfer[0].len = 1;
> > +             spi_message_add_tail(&spi_xfer[0], &m);
> > +
> > +             spi_xfer[1].tx_buf = phy->iobuf + 1;
> > +             spi_xfer[1].len = 3;
> > +             spi_message_add_tail(&spi_xfer[1], &m);
> > +
> > +             if (out) {
> > +                     spi_xfer[2].tx_buf = &phy->iobuf[4];
> > +                     spi_xfer[2].rx_buf = NULL;
> > +                     memcpy(&phy->iobuf[4], out, transfer_len);
> > +                     out += transfer_len;
> > +             }
> > +
> > +             if (in) {
> > +                     spi_xfer[2].tx_buf = NULL;
> > +                     spi_xfer[2].rx_buf = &phy->iobuf[4];
> > +             }
> > +
> > +             spi_xfer[2].len = transfer_len;
> > +             spi_message_add_tail(&spi_xfer[2], &m);
> > +
> > +             reinit_completion(&phy->ready);
> 
> What breaks without reinit? Or what sense made by init-ing it again?
When length is over frame size, this loop will run for more than
one iterations. Reinit to start transfer again.
KY
> > +
> > +             ret = spi_sync_locked(phy->spi_device, &m);
> > +             if (ret < 0)
> > +                     return ret;
> > +
> > +             if (in) {
> > +                     memcpy(in, &phy->iobuf[4], transfer_len);
> > +                     in += transfer_len;
> > +             }
> > +
> > +             len -= transfer_len;
> > +     }
> > +
> > +     return ret;
> > +}