On Wed, Mar 01, 2023 at 03:09:24PM +0100, Thierry Reding wrote: > 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. If more HW uses this feature it will likely look a lot like these tegra drivers where an existing supported SPI driver gains a HW bit to do the flow. Meaning DTs will exist configuring a TPM to a half duplex SPI and kernels will exist that don't have the HW driver that implements it. So, I would like it if old kernels running against a new DT do not mis-operate the SPI because their SPI driver does not support TPM operation. Either because the spi layer refuses the request as unsupported or the TPM layer refuses to use the spi driver as unsupported. I do not like the idea that the SPI subsystem will take a request from a client driver and silently mis-execute it. Jason