diff mbox series

[V10,2/3] tpm_tis-spi: Add hardware wait polling

Message ID 20230421091309.2672-3-kyarlagadda@nvidia.com
State New
Headers
Series Tegra TPM driver with HW flow control |

Commit Message

Krishna Yarlagadda April 21, 2023, 9:13 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.

The current TPM TIS driver only supports software detection of the wait
signal. To support SPI controllers that use hardware to detect the wait
signal, add the function tpm_tis_spi_hw_flow_transfer() and move the
existing code for software based detection into a function called
tpm_tis_spi_sw_flow_transfer(). SPI controllers that only support
half-duplex transfers will always call tpm_tis_spi_hw_flow_transfer()
because they cannot support software based detection. The bit
SPI_TPM_HW_FLOW is set to indicate to the SPI controller that hardware
detection is required and it is the responsibility of the SPI controller
driver to determine if this is supported or not.

For hardware flow control, CMD-ADDR-DATA messages are combined into a
single message where as for software flow control exiting method of
CMD-ADDR in a message and DATA in another is followed.

Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com>
---
 drivers/char/tpm/tpm_tis_spi_main.c | 91 ++++++++++++++++++++++++++++-
 1 file changed, 89 insertions(+), 2 deletions(-)

Comments

Jarkko Sakkinen April 23, 2023, 3:08 p.m. UTC | #1 
On Fri Apr 21, 2023 at 12:13 PM EEST, Krishna Yarlagadda wrote:
> 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.
>
> The current TPM TIS driver only supports software detection of the wait
> signal. To support SPI controllers that use hardware to detect the wait
> signal, add the function tpm_tis_spi_hw_flow_transfer() and move the
> existing code for software based detection into a function called
> tpm_tis_spi_sw_flow_transfer(). SPI controllers that only support
> half-duplex transfers will always call tpm_tis_spi_hw_flow_transfer()
> because they cannot support software based detection. The bit
> SPI_TPM_HW_FLOW is set to indicate to the SPI controller that hardware
> detection is required and it is the responsibility of the SPI controller
> driver to determine if this is supported or not.
>
> For hardware flow control, CMD-ADDR-DATA messages are combined into a
> single message where as for software flow control exiting method of
> CMD-ADDR in a message and DATA in another is followed.
>
> Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com>
> ---
>  drivers/char/tpm/tpm_tis_spi_main.c | 91 ++++++++++++++++++++++++++++-
>  1 file changed, 89 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c
> index a0963a3e92bd..8967f179f808 100644
> --- a/drivers/char/tpm/tpm_tis_spi_main.c
> +++ b/drivers/char/tpm/tpm_tis_spi_main.c
> @@ -71,8 +71,74 @@ static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy *phy,
>  	return 0;
>  }
>  
> -int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
> -			 u8 *in, const u8 *out)
> +/*
> + * Half duplex controller with support for TPM wait state detection like
> + * Tegra QSPI need CMD, ADDR & DATA sent in single message to manage HW flow
> + * control. Each phase sent in different transfer for controller to idenity
> + * phase.
> + */
> +static int tpm_tis_spi_transfer_half(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);
> +
> +		ret = spi_sync(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;
> +}
> +
> +static int tpm_tis_spi_transfer_full(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);
>  	int ret = 0;
> @@ -140,6 +206,24 @@ int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
>  	return ret;
>  }
>  
> +int tpm_tis_spi_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_controller *ctlr = phy->spi_device->controller;
> +
> +	/*
> +	 * TPM flow control over SPI requires full duplex support.
> +	 * Send entire message to a half duplex controller to handle
> +	 * wait polling in controller.
> +	 * Set TPM HW flow control flag..
> +	 */
> +	if (ctlr->flags & SPI_CONTROLLER_HALF_DUPLEX)
> +		return tpm_tis_spi_transfer_half(data, addr, len, in, out);
> +	else
> +		return tpm_tis_spi_transfer_full(data, addr, len, in, out);
> +}
> +
>  static int tpm_tis_spi_read_bytes(struct tpm_tis_data *data, u32 addr,
>  				  u16 len, u8 *result, enum tpm_tis_io_mode io_mode)
>  {
> @@ -181,6 +265,9 @@ static int tpm_tis_spi_probe(struct spi_device *dev)
>  
>  	phy->flow_control = tpm_tis_spi_flow_control;
>  
> +	if (dev->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)
> +		dev->mode |= SPI_TPM_HW_FLOW;
> +
>  	/* If the SPI device has an IRQ then use that */
>  	if (dev->irq > 0)
>  		irq = dev->irq;
> -- 
> 2.17.1

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

Should I pick these patches?

BR, Jarkko
Mark Brown April 24, 2023, 11:56 a.m. UTC | #2 
On Sun, Apr 23, 2023 at 06:08:16PM +0300, Jarkko Sakkinen wrote:

> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

> Should I pick these patches?

I've queued the spi side already.
Jarkko Sakkinen April 24, 2023, 1:11 p.m. UTC | #3 
On Mon, 2023-04-24 at 12:56 +0100, Mark Brown wrote:
> On Sun, Apr 23, 2023 at 06:08:16PM +0300, Jarkko Sakkinen wrote:
> 
> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> > Should I pick these patches?
> 
> I've queued the spi side already.

OK, great, thanks.

BR, Jarkko
Thierry Reding April 24, 2023, 2:46 p.m. UTC | #4 
On Mon, Apr 24, 2023 at 12:56:25PM +0100, Mark Brown wrote:
> On Sun, Apr 23, 2023 at 06:08:16PM +0300, Jarkko Sakkinen wrote:
> 
> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> > Should I pick these patches?
> 
> I've queued the spi side already.

Mark,

Would it make sense for you to pick up patch 2/3 as well? As far as I
can tell there's a build dependency on patch 1/3 because of the newly
added SPI_TPM_HW_FLOW symbol.

Thierry
Mark Brown April 24, 2023, 3:18 p.m. UTC | #5 
On Mon, Apr 24, 2023 at 04:46:24PM +0200, Thierry Reding wrote:

> Would it make sense for you to pick up patch 2/3 as well? As far as I
> can tell there's a build dependency on patch 1/3 because of the newly
> added SPI_TPM_HW_FLOW symbol.

I'll include it in my pull request for spi this time round so it should
end up in -rc1, my thinking was that I was happy with the SPI bits and
if it was in -rc1 then the TPM bits could be handled without cross tree
issues when the review was sorted (which it is now but wasn't at the
time).  If the SPI side doesn't make -rc1 for some reason I can pick up
the TPM bit as well, and/or do a signed tag.
Thierry Reding April 24, 2023, 3:31 p.m. UTC | #6 
On Mon, Apr 24, 2023 at 04:18:45PM +0100, Mark Brown wrote:
> On Mon, Apr 24, 2023 at 04:46:24PM +0200, Thierry Reding wrote:
> 
> > Would it make sense for you to pick up patch 2/3 as well? As far as I
> > can tell there's a build dependency on patch 1/3 because of the newly
> > added SPI_TPM_HW_FLOW symbol.
> 
> I'll include it in my pull request for spi this time round so it should
> end up in -rc1, my thinking was that I was happy with the SPI bits and
> if it was in -rc1 then the TPM bits could be handled without cross tree
> issues when the review was sorted (which it is now but wasn't at the
> time).  If the SPI side doesn't make -rc1 for some reason I can pick up
> the TPM bit as well, and/or do a signed tag.

Sounds good.

Thanks,
Thierry
Krishna Yarlagadda May 10, 2023, 3:10 p.m. UTC | #7 
> -----Original Message-----
> From: Thierry Reding <thierry.reding@gmail.com>
> Sent: 24 April 2023 21:02
> To: Mark Brown <broonie@kernel.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>; Krishna Yarlagadda
> <kyarlagadda@nvidia.com>; jsnitsel@redhat.com; robh+dt@kernel.org;
> peterhuewe@gmx.de; jgg@ziepe.ca; krzysztof.kozlowski+dt@linaro.org;
> linux-spi@vger.kernel.org; linux-tegra@vger.kernel.org; linux-
> integrity@vger.kernel.org; linux-kernel@vger.kernel.org; Jonathan Hunter
> <jonathanh@nvidia.com>; Sowjanya Komatineni
> <skomatineni@nvidia.com>; Laxman Dewangan <ldewangan@nvidia.com>
> Subject: Re: [Patch V10 2/3] tpm_tis-spi: Add hardware wait polling
> 
> On Mon, Apr 24, 2023 at 04:18:45PM +0100, Mark Brown wrote:
> > On Mon, Apr 24, 2023 at 04:46:24PM +0200, Thierry Reding wrote:
> >
> > > Would it make sense for you to pick up patch 2/3 as well? As far as I
> > > can tell there's a build dependency on patch 1/3 because of the newly
> > > added SPI_TPM_HW_FLOW symbol.
> >
> > I'll include it in my pull request for spi this time round so it should
> > end up in -rc1, my thinking was that I was happy with the SPI bits and
> > if it was in -rc1 then the TPM bits could be handled without cross tree
> > issues when the review was sorted (which it is now but wasn't at the
> > time).  If the SPI side doesn't make -rc1 for some reason I can pick up
> > the TPM bit as well, and/or do a signed tag.
> 
> Sounds good.
> 
> Thanks,
> Thierry

Mark,
Now that SPI changes are in, can we pull this TPM change for rc2.
Will this be picked into SPI or TPM list?
Thanks,
KY
Krishna Yarlagadda May 24, 2023, 12:43 p.m. UTC | #8 
> -----Original Message-----
> From: Krishna Yarlagadda <kyarlagadda@nvidia.com>
> Sent: Wednesday, May 10, 2023 8:41 PM
> To: Thierry Reding <thierry.reding@gmail.com>; Mark Brown
> <broonie@kernel.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>; jsnitsel@redhat.com;
> robh+dt@kernel.org; peterhuewe@gmx.de; jgg@ziepe.ca;
> krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; linux-
> tegra@vger.kernel.org; linux-integrity@vger.kernel.org; linux-
> kernel@vger.kernel.org; Jonathan Hunter <jonathanh@nvidia.com>;
> Sowjanya Komatineni <skomatineni@nvidia.com>; Laxman Dewangan
> <ldewangan@nvidia.com>
> Subject: RE: [Patch V10 2/3] tpm_tis-spi: Add hardware wait polling
> 
> 
> > -----Original Message-----
> > From: Thierry Reding <thierry.reding@gmail.com>
> > Sent: 24 April 2023 21:02
> > To: Mark Brown <broonie@kernel.org>
> > Cc: Jarkko Sakkinen <jarkko@kernel.org>; Krishna Yarlagadda
> > <kyarlagadda@nvidia.com>; jsnitsel@redhat.com; robh+dt@kernel.org;
> > peterhuewe@gmx.de; jgg@ziepe.ca; krzysztof.kozlowski+dt@linaro.org;
> > linux-spi@vger.kernel.org; linux-tegra@vger.kernel.org; linux-
> > integrity@vger.kernel.org; linux-kernel@vger.kernel.org; Jonathan Hunter
> > <jonathanh@nvidia.com>; Sowjanya Komatineni
> > <skomatineni@nvidia.com>; Laxman Dewangan <ldewangan@nvidia.com>
> > Subject: Re: [Patch V10 2/3] tpm_tis-spi: Add hardware wait polling
> >
> > On Mon, Apr 24, 2023 at 04:18:45PM +0100, Mark Brown wrote:
> > > On Mon, Apr 24, 2023 at 04:46:24PM +0200, Thierry Reding wrote:
> > >
> > > > Would it make sense for you to pick up patch 2/3 as well? As far as I
> > > > can tell there's a build dependency on patch 1/3 because of the newly
> > > > added SPI_TPM_HW_FLOW symbol.
> > >
> > > I'll include it in my pull request for spi this time round so it should
> > > end up in -rc1, my thinking was that I was happy with the SPI bits and
> > > if it was in -rc1 then the TPM bits could be handled without cross tree
> > > issues when the review was sorted (which it is now but wasn't at the
> > > time).  If the SPI side doesn't make -rc1 for some reason I can pick up
> > > the TPM bit as well, and/or do a signed tag.
> >
> > Sounds good.
> >
> > Thanks,
> > Thierry
> 
> Mark,
> Now that SPI changes are in, can we pull this TPM change for rc2.
> Will this be picked into SPI or TPM list?
Jarkko, Mark,
Can we pick this change in TPM list since SPI header changes are in.

Regards
KY
> Thanks,
> KY
Thierry Reding June 1, 2023, 8:29 a.m. UTC | #9 
On Wed, May 24, 2023 at 12:43:12PM +0000, Krishna Yarlagadda wrote:
> > -----Original Message-----
> > From: Krishna Yarlagadda <kyarlagadda@nvidia.com>
> > Sent: Wednesday, May 10, 2023 8:41 PM
> > To: Thierry Reding <thierry.reding@gmail.com>; Mark Brown
> > <broonie@kernel.org>
> > Cc: Jarkko Sakkinen <jarkko@kernel.org>; jsnitsel@redhat.com;
> > robh+dt@kernel.org; peterhuewe@gmx.de; jgg@ziepe.ca;
> > krzysztof.kozlowski+dt@linaro.org; linux-spi@vger.kernel.org; linux-
> > tegra@vger.kernel.org; linux-integrity@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Jonathan Hunter <jonathanh@nvidia.com>;
> > Sowjanya Komatineni <skomatineni@nvidia.com>; Laxman Dewangan
> > <ldewangan@nvidia.com>
> > Subject: RE: [Patch V10 2/3] tpm_tis-spi: Add hardware wait polling
> > 
> > 
> > > -----Original Message-----
> > > From: Thierry Reding <thierry.reding@gmail.com>
> > > Sent: 24 April 2023 21:02
> > > To: Mark Brown <broonie@kernel.org>
> > > Cc: Jarkko Sakkinen <jarkko@kernel.org>; Krishna Yarlagadda
> > > <kyarlagadda@nvidia.com>; jsnitsel@redhat.com; robh+dt@kernel.org;
> > > peterhuewe@gmx.de; jgg@ziepe.ca; krzysztof.kozlowski+dt@linaro.org;
> > > linux-spi@vger.kernel.org; linux-tegra@vger.kernel.org; linux-
> > > integrity@vger.kernel.org; linux-kernel@vger.kernel.org; Jonathan Hunter
> > > <jonathanh@nvidia.com>; Sowjanya Komatineni
> > > <skomatineni@nvidia.com>; Laxman Dewangan <ldewangan@nvidia.com>
> > > Subject: Re: [Patch V10 2/3] tpm_tis-spi: Add hardware wait polling
> > >
> > > On Mon, Apr 24, 2023 at 04:18:45PM +0100, Mark Brown wrote:
> > > > On Mon, Apr 24, 2023 at 04:46:24PM +0200, Thierry Reding wrote:
> > > >
> > > > > Would it make sense for you to pick up patch 2/3 as well? As far as I
> > > > > can tell there's a build dependency on patch 1/3 because of the newly
> > > > > added SPI_TPM_HW_FLOW symbol.
> > > >
> > > > I'll include it in my pull request for spi this time round so it should
> > > > end up in -rc1, my thinking was that I was happy with the SPI bits and
> > > > if it was in -rc1 then the TPM bits could be handled without cross tree
> > > > issues when the review was sorted (which it is now but wasn't at the
> > > > time).  If the SPI side doesn't make -rc1 for some reason I can pick up
> > > > the TPM bit as well, and/or do a signed tag.
> > >
> > > Sounds good.
> > >
> > > Thanks,
> > > Thierry
> > 
> > Mark,
> > Now that SPI changes are in, can we pull this TPM change for rc2.
> > Will this be picked into SPI or TPM list?
> Jarkko, Mark,
> Can we pick this change in TPM list since SPI header changes are in.

Hey Mark, Jarkko,

any ideas on how we can best get this merged? I guess at this point it
could go through either tree since the SPI dependency has been in Linus'
tree since v6.4-rc1.

Thierry
Mark Brown June 1, 2023, 11:04 a.m. UTC | #10 
On Thu, Jun 01, 2023 at 10:29:51AM +0200, Thierry Reding wrote:

> any ideas on how we can best get this merged? I guess at this point it
> could go through either tree since the SPI dependency has been in Linus'
> tree since v6.4-rc1.

I would expect it to go via whatever path TPM patches usually take given
that it's a TPM patch.
Thierry Reding June 1, 2023, 12:36 p.m. UTC | #11 
On Thu, Jun 01, 2023 at 12:04:59PM +0100, Mark Brown wrote:
> On Thu, Jun 01, 2023 at 10:29:51AM +0200, Thierry Reding wrote:
> 
> > any ideas on how we can best get this merged? I guess at this point it
> > could go through either tree since the SPI dependency has been in Linus'
> > tree since v6.4-rc1.
> 
> I would expect it to go via whatever path TPM patches usually take given
> that it's a TPM patch.

There might have been a misunderstanding. My recollection was that you
had said a few weeks ago that you would pick this up. Going through the
thread again I realize that may not have been what you meant. Perhaps
Jarkko misinterpreted this in the same way.

Jarkko, can you pick this up for v6.5?

Thierry
Mark Brown June 1, 2023, 12:40 p.m. UTC | #12 
On Thu, Jun 01, 2023 at 02:36:51PM +0200, Thierry Reding wrote:
> On Thu, Jun 01, 2023 at 12:04:59PM +0100, Mark Brown wrote:

> > On Thu, Jun 01, 2023 at 10:29:51AM +0200, Thierry Reding wrote:

> > > any ideas on how we can best get this merged? I guess at this point it
> > > could go through either tree since the SPI dependency has been in Linus'
> > > tree since v6.4-rc1.

> > I would expect it to go via whatever path TPM patches usually take given
> > that it's a TPM patch.

> There might have been a misunderstanding. My recollection was that you
> had said a few weeks ago that you would pick this up. Going through the
> thread again I realize that may not have been what you meant. Perhaps
> Jarkko misinterpreted this in the same way.

> Jarkko, can you pick this up for v6.5?

No, I said that I had applied the SPI parts for v6.4 so there would be
no blocker whenever people got round to reviewing the TPM side.
Jarkko Sakkinen June 9, 2023, 2:19 p.m. UTC | #13 
On Thu Jun 1, 2023 at 3:40 PM EEST, Mark Brown wrote:
> On Thu, Jun 01, 2023 at 02:36:51PM +0200, Thierry Reding wrote:
> > On Thu, Jun 01, 2023 at 12:04:59PM +0100, Mark Brown wrote:
>
> > > On Thu, Jun 01, 2023 at 10:29:51AM +0200, Thierry Reding wrote:
>
> > > > any ideas on how we can best get this merged? I guess at this point it
> > > > could go through either tree since the SPI dependency has been in Linus'
> > > > tree since v6.4-rc1.
>
> > > I would expect it to go via whatever path TPM patches usually take given
> > > that it's a TPM patch.
>
> > There might have been a misunderstanding. My recollection was that you
> > had said a few weeks ago that you would pick this up. Going through the
> > thread again I realize that may not have been what you meant. Perhaps
> > Jarkko misinterpreted this in the same way.
>
> > Jarkko, can you pick this up for v6.5?
>
> No, I said that I had applied the SPI parts for v6.4 so there would be
> no blocker whenever people got round to reviewing the TPM side.

I'm totally cool with this: won't pick the patch then.

BR, Jarkko
Mark Brown June 9, 2023, 2:22 p.m. UTC | #14 
On Fri, Jun 09, 2023 at 05:19:15PM +0300, Jarkko Sakkinen wrote:
> On Thu Jun 1, 2023 at 3:40 PM EEST, Mark Brown wrote:
> > On Thu, Jun 01, 2023 at 02:36:51PM +0200, Thierry Reding wrote:
> > > On Thu, Jun 01, 2023 at 12:04:59PM +0100, Mark Brown wrote:
> > > > On Thu, Jun 01, 2023 at 10:29:51AM +0200, Thierry Reding wrote:

> > > Jarkko, can you pick this up for v6.5?

> > No, I said that I had applied the SPI parts for v6.4 so there would be
> > no blocker whenever people got round to reviewing the TPM side.

> I'm totally cool with this: won't pick the patch then.

I have no intention of applying the patch, I am expecting it to go via
the TPM tree.
Jarkko Sakkinen June 9, 2023, 3:12 p.m. UTC | #15 
On Fri Jun 9, 2023 at 5:22 PM EEST, Mark Brown wrote:
> On Fri, Jun 09, 2023 at 05:19:15PM +0300, Jarkko Sakkinen wrote:
> > On Thu Jun 1, 2023 at 3:40 PM EEST, Mark Brown wrote:
> > > On Thu, Jun 01, 2023 at 02:36:51PM +0200, Thierry Reding wrote:
> > > > On Thu, Jun 01, 2023 at 12:04:59PM +0100, Mark Brown wrote:
> > > > > On Thu, Jun 01, 2023 at 10:29:51AM +0200, Thierry Reding wrote:
>
> > > > Jarkko, can you pick this up for v6.5?
>
> > > No, I said that I had applied the SPI parts for v6.4 so there would be
> > > no blocker whenever people got round to reviewing the TPM side.
>
> > I'm totally cool with this: won't pick the patch then.
>
> I have no intention of applying the patch, I am expecting it to go via
> the TPM tree.

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=8638bedb01ab6170d7dbd1ceaefa5e82639c432d

I'll mirror publish this in my next branch (mirrored to linux-next) soon.

BR, Jarkko
diff mbox series

Patch

diff --git a/drivers/char/tpm/tpm_tis_spi_main.c b/drivers/char/tpm/tpm_tis_spi_main.c
index a0963a3e92bd..8967f179f808 100644
--- a/drivers/char/tpm/tpm_tis_spi_main.c
+++ b/drivers/char/tpm/tpm_tis_spi_main.c
@@ -71,8 +71,74 @@  static int tpm_tis_spi_flow_control(struct tpm_tis_spi_phy *phy,
 	return 0;
 }
 
-int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
-			 u8 *in, const u8 *out)
+/*
+ * Half duplex controller with support for TPM wait state detection like
+ * Tegra QSPI need CMD, ADDR & DATA sent in single message to manage HW flow
+ * control. Each phase sent in different transfer for controller to idenity
+ * phase.
+ */
+static int tpm_tis_spi_transfer_half(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);
+
+		ret = spi_sync(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;
+}
+
+static int tpm_tis_spi_transfer_full(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);
 	int ret = 0;
@@ -140,6 +206,24 @@  int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
 	return ret;
 }
 
+int tpm_tis_spi_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_controller *ctlr = phy->spi_device->controller;
+
+	/*
+	 * TPM flow control over SPI requires full duplex support.
+	 * Send entire message to a half duplex controller to handle
+	 * wait polling in controller.
+	 * Set TPM HW flow control flag..
+	 */
+	if (ctlr->flags & SPI_CONTROLLER_HALF_DUPLEX)
+		return tpm_tis_spi_transfer_half(data, addr, len, in, out);
+	else
+		return tpm_tis_spi_transfer_full(data, addr, len, in, out);
+}
+
 static int tpm_tis_spi_read_bytes(struct tpm_tis_data *data, u32 addr,
 				  u16 len, u8 *result, enum tpm_tis_io_mode io_mode)
 {
@@ -181,6 +265,9 @@  static int tpm_tis_spi_probe(struct spi_device *dev)
 
 	phy->flow_control = tpm_tis_spi_flow_control;
 
+	if (dev->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)
+		dev->mode |= SPI_TPM_HW_FLOW;
+
 	/* If the SPI device has an IRQ then use that */
 	if (dev->irq > 0)
 		irq = dev->irq;