> > > [...]
> > > These definitions match Linux' tpm_tis_core.h. > > > > > > Should they be moved to an include of the same name in U-Boot? > > > > I got a tpm_tis.h in this series, so I might as well move those there > > > > > > > > > [...] > > > > > I would prefer if you would add these functions to a structure struct > > > tpm_tis_phy_ops which you can use to pull out the core driver. > > > > Me too :). In fact that matches the design I proposed over IRC. I just > > didn't have too much free time to fix it, so I went ahead and posted the > > driver matching what's already in U-Boot. That being said, what's proposed > > here is the right was forward. Basically if we do it like this then any > > future TPM TIS driver will only have to define the read/write ops for the > > underlyng bus. > > I'm not sure about the irc side, but it is best to do things on the > mailing list so people can see it. > > There seems to be quite a bit of duplicated code in this new driver. I > think it would be better to come up with the interface first, as > Heinrich suggests. Would something like regmap be good enough? > There's duplicated code in *every* TPM driver we have right now. That.. includes the cr50 and the TPM2 spi implementation we have. That's why I posted it as is. The interface you are looking for is the TIS described one from TCG. I am not sure if regmap is a good idea in that regard, but since I agree with both of you that having an abstracted TIS core makes sense in general, I'll go ahead and split my code. Then we can take a step back and port the remaining drivers to that. Cheers /Ilias > Regards, > Simon