public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Johannes Holland <johannes.holland@infineon.com>,
	Masahisa Kojima <masahisa.kojima@linaro.org>,
	Dhananjay Phadke <dphadke@linux.microsoft.com>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 2/2] tpm2: Add a TPMv2 MMIO TIS driver
Date: Wed, 14 Jul 2021 08:23:24 +0300	[thread overview]
Message-ID: <YO50zHu5y8vbfOMe@enceladus> (raw)
In-Reply-To: <CAPnjgZ2uf83gaTHWH0r2rDHvqb_irhqfu3iy=BjfTucU+ntmWA@mail.gmail.com>

On Tue, Jul 13, 2021 at 08:49:21PM -0600, Simon Glass wrote:
> Hi Ilias,
> 
> On Tue, 13 Jul 2021 at 14:11, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> >
> > [...]
> > > > > Should be a uclass interface.
> > > > >
> > > >
> > > > Why? A uclass is supposed to describe and abstract hardware.  This is just
> > > > a specific implementation of a TPM, not all TPMs are TIS compliant. We already
> > > > have a uclass for those.
> > >
> > > Who told you that a uclass is supposed to describe and abstract hardware? :-)
> > >
> >
> > That's what I've mostly seen it used for, maybe i got the idea wrong.
> 
> A uclass is basically a software construct. It is an interface between
> clients and the driver, typically. Quite often the uclass is an
> interface on top of the hardware (actually the driver). But quite
> often it is not. For example, we use an GPIO uclass to access a pmic's
> GPIOs, we use an I2C uclass to access the cros_ec I2C tunnel. Anywhere
> where it makes sense to have an abstraction, we use a uclass.
> 
> >
> > > The uclass is how driver model does APIs, so normally a uclass would
> > > be used for any API. There are exceptions, but this one actually looks
> > > like a useful interface we should have.
> > >
> >
> > the point is we already have a uclass for tpm devices.  So why should the
> > we add another one that just describes the TIS interface?
> 
> You have already added another API, right? All we are discussing is
> whether it should be a uclass or not. Unless there is a very good
> reason, we should avoid creating custom interfaces that don't use
> driver model. I actually think the interface you've created (MMIO)
> will be very useful as a uclass.
> 

So you are basically looking into adding something similar to
dm_i2c_read/dm_i2c_write etc?
I assume this is gong to be the default read method passed on the TIS API
when we want to support i2c TPMs.
For the MMIO case that would essentially mean, move the functions on a
different file, add them on a header and define a UCLASS_DRIVER with only
the .id and .name defined?

Thanks
/Ilias

> [..]
> 
> Regards,
> Simon

  reply	other threads:[~2021-07-14  5:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 16:25 [PATCH 1/2 v2] tpm2: Introduce TIS tpm core Ilias Apalodimas
2021-07-07 16:25 ` [PATCH 2/2] tpm2: Add a TPMv2 MMIO TIS driver Ilias Apalodimas
2021-07-11  0:00   ` Simon Glass
2021-07-12 18:22     ` Ilias Apalodimas
2021-07-12 19:13       ` Heinrich Schuchardt
2021-07-12 19:43         ` Simon Glass
2021-07-12 22:46           ` Heinrich Schuchardt
2021-07-13 16:52             ` Simon Glass
2021-07-12 19:38       ` Simon Glass
2021-07-13 20:11         ` Ilias Apalodimas
2021-07-14  2:49           ` Simon Glass
2021-07-14  5:23             ` Ilias Apalodimas [this message]
2021-07-14 19:50               ` Simon Glass
2021-07-11  0:00 ` [PATCH 1/2 v2] tpm2: Introduce TIS tpm core Simon Glass
2021-07-12  6:24   ` Ilias Apalodimas
2021-07-12 11:42     ` Simon Glass
2021-07-12 14:03       ` Ilias Apalodimas
2021-07-12 19:43         ` Simon Glass
2021-07-13  5:51           ` Ilias Apalodimas
2021-07-13 20:17             ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YO50zHu5y8vbfOMe@enceladus \
    --to=ilias.apalodimas@linaro.org \
    --cc=dphadke@linux.microsoft.com \
    --cc=johannes.holland@infineon.com \
    --cc=masahisa.kojima@linaro.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox