> -----Original Message-----
> From: Mark Brown <broonie@xxxxxxxxxx>
> Sent: 24 February 2023 21:22
> To: Krishna Yarlagadda <kyarlagadda@xxxxxxxxxx>
> Cc: robh+dt@xxxxxxxxxx; peterhuewe@xxxxxx; jgg@xxxxxxxx;
> jarkko@xxxxxxxxxx; krzysztof.kozlowski+dt@xxxxxxxxxx; linux-
> spi@xxxxxxxxxxxxxxx; linux-tegra@xxxxxxxxxxxxxxx; linux-
> integrity@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> thierry.reding@xxxxxxxxx; Jonathan Hunter <jonathanh@xxxxxxxxxx>;
> Sowjanya Komatineni <skomatineni@xxxxxxxxxx>; Laxman Dewangan
> <ldewangan@xxxxxxxxxx>
> 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.
