Messages in this thread | | | From | Krishna Yarlagadda <> | Subject | RE: [Patch V3 1/3] tpm_tis-spi: Support hardware wait polling | Date | Fri, 24 Feb 2023 16:21:17 +0000 |
| |
> -----Original Message----- > From: Mark Brown <broonie@kernel.org> > Sent: 24 February 2023 21:22 > To: Krishna Yarlagadda <kyarlagadda@nvidia.com> > Cc: robh+dt@kernel.org; peterhuewe@gmx.de; jgg@ziepe.ca; > jarkko@kernel.org; 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; > thierry.reding@gmail.com; Jonathan Hunter <jonathanh@nvidia.com>; > Sowjanya Komatineni <skomatineni@nvidia.com>; Laxman Dewangan > <ldewangan@nvidia.com> > Subject: Re: [Patch V3 1/3] tpm_tis-spi: Support hardware wait polling > > On Fri, Feb 24, 2023 at 02:16:27PM +0000, 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. > > > > No, why is there a bus lock? > > > Bus lock to avoid other clients to be accessed between TPM transfers. > > That's what a bus lock does but what would be the problem if something > else sent a message between messages? Note that a message will always > be sent atomically. QSPI has multi-chip-select support. Idea was to prevent transfers from both devices at the same time. But it should be fine if it is single message. I will verify with bus lock removed.
| |