All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.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: Mon, 12 Jul 2021 13:38:55 -0600	[thread overview]
Message-ID: <CAPnjgZ2TP0eP5WZmhoiVtAiyGDWUVp2nnd8J8YyqsUP591qk_Q@mail.gmail.com> (raw)
In-Reply-To: <YOyId3aZURsQ8O0D@enceladus>

Hi Ilias,

On Mon, 12 Jul 2021 at 12:22, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
> On Sat, Jul 10, 2021 at 06:00:59PM -0600, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Wed, 7 Jul 2021 at 10:26, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Add support for devices that expose a TPMv2 though MMIO.
> > > Apart from those devices, we can use the driver in our QEMU setups and
> > > test TPM related code which is difficult to achieve using the sandbox
> > > driver (e.g test the EFI TCG2 protocol).
> > >
> > > It's worth noting that a previous patch added TPMv2 TIS core functions,
> > > which the current driver is consuming.
> > >
> > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > ---
> > > Changes since v1:
> > > - split off the tis core code into a different file
> > >  drivers/tpm/Kconfig         |   9 +++
> > >  drivers/tpm/Makefile        |   1 +
> > >  drivers/tpm/tpm2_tis_mmio.c | 156 ++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 166 insertions(+)
> > >  create mode 100644 drivers/tpm/tpm2_tis_mmio.c
> >
> > Looks good to me
>
> Thanks!
>
> > >
> > > +struct tpm_tis_chip_data {
> > > +       unsigned int pcr_count;
> > > +       unsigned int pcr_select_min;
> > > +       unsigned int time_before_first_cmd_ms;
> > > +       void __iomem *iobase;
> > > +};
> >
> > comments
> >
>
> You mean on all the internal functions?
> Sure I can add them

I mean for struct members.

For internal functions a comment is a good idea depending on how
valuable it is - things like return values, args. But if just
implementing a fully documented API, it may not really add much.

>
> > > +
> > > +static int mmio_read_bytes(struct udevice *udev, u32 addr, u16 len,
> > > +                          u8 *result)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +
> > > +       while (len--)
> > > +               *result++ = ioread8(drv_data->iobase + addr);
> >
> > We normally put a blank line before the final return
> >
>
> sure
>
> > > +       return 0;
> > > +}
> > > +
> > > +static int mmio_write_bytes(struct udevice *udev, u32 addr, u16 len,
> > > +                           const u8 *value)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +
> > > +       while (len--)
> > > +               iowrite8(*value++, drv_data->iobase + addr);
> > > +       return 0;
> > > +}
> > > +
> > > +static int mmio_read16(struct udevice *udev, u32 addr, u16 *result)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +
> > > +       *result = ioread16(drv_data->iobase + addr);
> > > +       return 0;
> > > +}
> > > +
> > > +static int mmio_read32(struct udevice *udev, u32 addr, u32 *result)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +
> > > +       *result = ioread32(drv_data->iobase + addr);
> > > +       return 0;
> > > +}
> > > +
> > > +static int mmio_write32(struct udevice *udev, u32 addr, u32 value)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +
> > > +       iowrite32(value, drv_data->iobase + addr);
> > > +       return 0;
> > > +}
> > > +
> > > +static struct tpm_tis_phy_ops phy_ops = {
> >
> > 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? :-)

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.

>
> > > +       .read_bytes = mmio_read_bytes,
> > > +       .write_bytes = mmio_write_bytes,
> > > +       .read16 = mmio_read16,
> > > +       .read32 = mmio_read32,
> > > +       .write32 = mmio_write32,
> > > +};
> > > +
> > > +static int tpm_tis_probe(struct udevice *udev)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +       struct tpm_chip_priv *priv = dev_get_uclass_priv(udev);
> > > +       int ret = 0;
> > > +       fdt_addr_t ioaddr;
> > > +       u64 sz;
> > > +
> > > +       ioaddr = dev_read_addr(udev);
> > > +       if (ioaddr == FDT_ADDR_T_NONE)
> > > +               return -EINVAL;
> >
> > consider this for easier debugging:
> >
> >    return log_msg_ret("ioaddr", -EINVAL);
> >
>
> Sure
>
> > > +
> > > +       ret = dev_read_u64(udev, "reg", &sz);
> > > +       if (ret)
> > > +               return -EINVAL;
> > > +
> > > +       drv_data->iobase = ioremap(ioaddr, sz);
> > > +       log_info("Remapped TPM2 base: 0x%llx size: 0x%llx\n", ioaddr, sz);
> >
> > log_debug() I think?
> >
> Yea, that's a leftover of my initial code, were I needed to make sure the
> ioremap worked.
>
> > > +       tpm_tis_ops_register(udev, &phy_ops);
> > > +       ret = tpm_tis_init(udev);
> > > +       if (ret)
> > > +               goto iounmap;
> > > +
> > > +       priv->pcr_count = drv_data->pcr_count;
> > > +       priv->pcr_select_min = drv_data->pcr_select_min;
> > > +       /*
> > > +        * Although the driver probably works with a TPMv1 our Kconfig
> > > +        * limits the driver to TPMv2 only
> > > +        */
> > > +       priv->version = TPM_V2;
> > > +
> > > +       return ret;
> > > +iounmap:
> > > +       iounmap(drv_data->iobase);
> > > +       return -EINVAL;
> > > +}
> > > +
> > > +static int tpm_tis_remove(struct udevice *udev)
> > > +{
> > > +       struct tpm_tis_chip_data *drv_data = (void *)dev_get_driver_data(udev);
> > > +
> > > +       iounmap(drv_data->iobase);
> > > +       return tpm_tis_cleanup(udev);
> > > +}
> > > +
> > > +static const struct tpm_ops tpm_tis_ops = {
> > > +       .open           = tpm_tis_open,
> > > +       .close          = tpm_tis_close,
> > > +       .get_desc       = tpm_tis_get_desc,
> > > +       .send           = tpm_tis_send,
> > > +       .recv           = tpm_tis_recv,
> > > +       .cleanup        = tpm_tis_cleanup,
> > > +};
> > > +
> > > +static const struct tpm_tis_chip_data tpm_tis_std_chip_data = {
> > > +       .pcr_count = 24,
> > > +       .pcr_select_min = 3,
> > > +};
> > > +
> > > +static const struct udevice_id tpm_tis_ids[] = {
> > > +       {
> > > +               .compatible = "tcg,tpm-tis-mmio",
> > > +               .data = (ulong)&tpm_tis_std_chip_data,
> > > +       },
> > > +       { }
> > > +};
> > > +
> > > +U_BOOT_DRIVER(tpm_tis_mmio) = {
> > > +       .name   = "tpm_tis_mmio",
> > > +       .id     = UCLASS_TPM,
> > > +       .of_match = tpm_tis_ids,
> > > +       .ops    = &tpm_tis_ops,
> > > +       .probe  = tpm_tis_probe,
> > > +       .remove = tpm_tis_remove,
> > > +       .priv_auto      = sizeof(struct tpm_chip),
> > > +};
> > > --
> > > 2.32.0.rc0
> > >
> >
> > Regards,
> > Simon
>
> Thanks for looking at this
> /Ilias

Likewise.

Regards,
Simon

  parent reply	other threads:[~2021-07-12 19:39 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 [this message]
2021-07-13 20:11         ` Ilias Apalodimas
2021-07-14  2:49           ` Simon Glass
2021-07-14  5:23             ` Ilias Apalodimas
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=CAPnjgZ2TP0eP5WZmhoiVtAiyGDWUVp2nnd8J8YyqsUP591qk_Q@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=dphadke@linux.microsoft.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=johannes.holland@infineon.com \
    --cc=masahisa.kojima@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.