On Wed, Mar 01, 2023 at 09:39:28AM -0400, Jason Gunthorpe wrote: > On Wed, Mar 01, 2023 at 12:37:27PM +0000, Mark Brown wrote: > > On Wed, Mar 01, 2023 at 08:27:45AM -0400, Jason Gunthorpe wrote: > > > On Wed, Mar 01, 2023 at 11:56:53AM +0000, Krishna Yarlagadda wrote: > > > > > > TPM device connected behind half duplex controller can only work > > > > this way. So, no additional flag needed to check. > > > > > Just because a DT hooks it up this way doesn't mean the kernel driver > > > can support it, eg support hasn't been implemented in an older SPI > > > driver or something. > > > > > If the failure mode is anything other than the TPM doesn't probe we > > > will need to check for support. > > > > It's not like these buses are hot pluggable - someone would have to > > design and manufacture a board which doesn't work. It's probably > > reasonable for this to fail with the SPI subsystem saying it can't > > support things when the operation is tried. > > If the spi subsystem fails this request with these flags that would be > great, it would cause the TPM to fail probing reliably. > > But does this patch do that? It looks like non-supporting half duplex > drivers will just ignore the new flag? I think the assumption is that there are currently no half duplex drivers that would be impacted by this. If I understand correctly, the TPM driver currently supports only full duplex controllers, because that's required in order to detect the wait state in software. So, yes, half duplex controllers would ignore this flag, but since they couldn't have supported TPM flow control before anyway it doesn't make a difference. Thierry
Attachment:
signature.asc
Description: PGP signature
