From mboxrd@z Thu Jan  1 00:00:00 1970
From: Miquel Raynal <miquel.raynal@bootlin.com>
Date: Tue, 20 Mar 2018 14:36:56 +0100
Subject: [U-Boot] [PATCH 00/18] Introduce SPI TPM v2.0 support
In-Reply-To: <20180309121840.GG1770@bill-the-cat.ec.rr.com>
References: <20180308154021.25255-1-miquel.raynal@bootlin.com>
 <20180308172030.GA1770@bill-the-cat.ec.rr.com>
 <20180309085340.32cf1730@xps13>
 <20180309121840.GG1770@bill-the-cat.ec.rr.com>
Message-ID: <20180320143656.4c1ae678@xps13>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: u-boot@lists.denx.de

Hi Tom,

Sorry for the delay.

On Fri, 9 Mar 2018 07:18:40 -0500, Tom Rini <trini@konsulko.com> wrote:

> On Fri, Mar 09, 2018 at 08:53:40AM +0100, Miquel Raynal wrote:
> > Hi Tom,
> >=20
> > On Thu, 8 Mar 2018 12:20:30 -0500, Tom Rini <trini@konsulko.com> wrote:
> >  =20
> > > On Thu, Mar 08, 2018 at 04:40:03PM +0100, Miquel Raynal wrote:
> > >  =20
> > > > Current U-Boot supports TPM v1.2 specification. The new specificati=
on
> > > > (v2.0) is not backward compatible and renames/introduces several
> > > > functions.
> > > >=20
> > > > This series introduces a new SPI driver following the TPM v2.0
> > > > specification. It has been tested on a ST TPM but should be usable =
with
> > > > others v2.0 compliant chips.
> > > >=20
> > > > Then, basic functionalities are introduced one by one for the v2.0
> > > > specification. The INIT command now can receive a parameter to
> > > > distinguish further TPMv1/TPMv2 commands. After that, the library i=
tself
> > > > will know which one is pertinent and will return a special error if=
 the
> > > > desired command is not supported for the selected specification.   =
=20
> > >=20
> > > Thanks for doing all of this.  Can you please enable this feature on
> > > sandbox and/or an x86 QEMU variant where I assume we could also then
> > > setup automated testing?
> > >  =20
> >=20
> > Not sure I understand your request correctly: the TPM commands are
> > already available in the sandbox (I don't see what I could add), I just
> > extended the current set of commands.
> >=20
> > However, even with these commands, we won't be able to test them in a
> > sandbox unless with an actual device.
> >=20
> > I probably miss something, can you explain a bit more what you would
> > like? =20
>=20
> Can we add a valid TPM via QEMU and then test it that way?  If so, we
> should enable the TPM code on qemu-x86_64 (and, well, if we can pass it
> on other arches, other QEMU targets) and write some test/py/tests/ code
> that exercises the TPM commands.  Does that make sense?
>=20

I suppose this is doable, but for what I know, the effort is
consequent. TPM 2.0 are not compatible at all with TPM 1.x , the
packets exchanged at TPM level are completely different. Hence, I
think there is almost nothing that we can take from the TPM 1.x
implementation already existing in QEMU.

I am certain we all would benefit such a contribution, however I'm
not sure I could handle that anytime soon.

About the series, I think it would be better that I change a macro name
("STRINGIFY", which is wrongly named), I will send a v2 soon, can you
tell me its status otherwise?

Thank you,
Miqu=C3=A8l=20

--=20
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com