[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM4PR12MB57695DE127286D1DA436E804C3AB9@DM4PR12MB5769.namprd12.prod.outlook.com>
Date: Thu, 23 Feb 2023 18:41:43 +0000
From: Krishna Yarlagadda <kyarlagadda@...dia.com>
To: Mark Brown <broonie@...nel.org>
CC: "robh+dt@...nel.org" <robh+dt@...nel.org>,
"peterhuewe@....de" <peterhuewe@....de>,
"jgg@...pe.ca" <jgg@...pe.ca>,
"jarkko@...nel.org" <jarkko@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Sowjanya Komatineni <skomatineni@...dia.com>,
Laxman Dewangan <ldewangan@...dia.com>
Subject: RE: [Patch V3 1/3] tpm_tis-spi: Support hardware wait polling
> -----Original Message-----
> From: Mark Brown <broonie@...nel.org>
> Sent: 23 February 2023 22:49
> To: Krishna Yarlagadda <kyarlagadda@...dia.com>
> Cc: robh+dt@...nel.org; peterhuewe@....de; jgg@...pe.ca;
> jarkko@...nel.org; krzysztof.kozlowski+dt@...aro.org; linux-
> spi@...r.kernel.org; linux-tegra@...r.kernel.org; linux-
> integrity@...r.kernel.org; linux-kernel@...r.kernel.org;
> thierry.reding@...il.com; Jonathan Hunter <jonathanh@...dia.com>;
> Sowjanya Komatineni <skomatineni@...dia.com>; Laxman Dewangan
> <ldewangan@...dia.com>
> Subject: Re: [Patch V3 1/3] tpm_tis-spi: Support hardware wait polling
>
> On Thu, Feb 23, 2023 at 09:56:33PM +0530, Krishna Yarlagadda wrote:
>
> > + spi_bus_lock(phy->spi_device->master);
> > +
> > + while (len) {
>
> Why?
TPM supports max 64B in single transaction. Loop to send rest of it.
>
> > + 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);
>
> Why would we make these two separate transfers?
Tegra QSPI combined sequence requires cmd, addr and data in different
transfers. This eliminates need for additional flag for combined sequence.
>
> > + 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];
> > + }
>
> This will use the same buffer for rx and tx if some bug manages to leave
> them both set. That shouldn't be an issue but it's an alarm bell
> reading the code.
>
> > index 988aabc31871..b88494e31239 100644
> > --- a/include/linux/spi/spi.h
> > +++ b/include/linux/spi/spi.h
> > @@ -184,8 +184,9 @@ struct spi_device {
> > u8 chip_select;
> > u8 bits_per_word;
> > bool rt;
> > -#define SPI_NO_TX BIT(31) /* No transmit wire */
> > -#define SPI_NO_RX BIT(30) /* No receive wire */
> > +#define SPI_NO_TX BIT(31) /* No transmit wire */
> > +#define SPI_NO_RX BIT(30) /* No receive wire */
> > +#define SPI_TPM_HW_FLOW BIT(29) /* TPM flow
> control */
>
> Additions to the SPI API should be a separate commit for SPI rather than
> merged into a driver change.
Will split this into new patch.
Powered by blists - more mailing lists