> -----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.