From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
Etienne Carriere <etienne.carriere@linaro.org>,
Jens Wiklander <jens.wiklander@linaro.org>,
Patrick Delaunay <patrick.delaunay@foss.st.com>
Subject: Re: [PATCH v4] tee: optee: rework TA bus scanning code
Date: Fri, 16 Sep 2022 23:18:32 +0300 [thread overview]
Message-ID: <YyTaGHpvRDOXOTgx@hera> (raw)
In-Reply-To: <CAPnjgZ2FfaU0=-KkJuZXYUsPTHnWBkSEhevWJWGAgcfn1d4qCg@mail.gmail.com>
Hi Simon,
> > > > > >
> > > > > > Late versions of OP-TEE support a pseudo bus. TAs that behave as
> > > > > > hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we can
> > > > > > scan. Unfortunately U-Boot doesn't support that yet. It's worth noting
> > > > > > that we already have a workaround for RNG. The details are in
> > > > > > commit 70812bb83da6 ("tee: optee: bind rng optee driver")
> > > > > >
> > > > > > So let's add a list of devices based on U-Boot Kconfig options that we will
> > > > > > scan until we properly implement the tee-bus functionality.
> > > > > >
> > > > > > While at it change the behaviour of the tee core itself wrt to device
> > > > > > binding. If some device binding fails, print a warning instead of
> > > > > > disabling OP-TEE.
> > > > > >
> > > > > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > > > Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
> > > > > > Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
> > > > > > ---
> > > > > > Changes since v3:
> > > > > > - Use NULL instead of a child ptr on device_bind_driver(), since it's not
> > > > > > really needed
> > > > > > - Changed the style of the optee_bus_probe[] definition to
> > > > > > {.drv_name = xxx, .dev_name = yyy }
> > > > > >
> > > > > > Changes since v2:
> > > > > > - Fixed typo on driver name ftpm-tee -> ftpm_tee
> > > > > >
> > > > > > Changes since v1:
> > > > > > - remove a macro and use ARRAY_SIZE directly
> > > > > > drivers/tee/optee/core.c | 24 +++++++++++++++++++-----
> > > > > > 1 file changed, 19 insertions(+), 5 deletions(-)
> > > > > >
[...]
> >
> > Some things *are* working without a DT entry. You had similar
> > concerns on FF-A (where you requested a DT node again) and people gave
> > the exact same response. As long as a bus is scanable in any way,
> > it's preferable to than adding a DT entry. Moreover this code does
> > not prevent anyone from adding a DT entry.
> >
> > To make things even worse if the TA is compiled as 'scanable' and has
> > a DT entry, it might cause issues down the road when being probed by
> > the kernel. So really this is just a patch that makes u-boot behave
> > and plug in properly to the rest of the ecosystem
>
> Calling device_bind() is supposed to be used in extremis. I don't see
> any scanning of an OP-TEE bus here. I just see it binding two child
> devices which are hard-coded in U-Boot. What am I missing?
The commit description describes the current state of U-Boot
>
> This appears to be a Linaro binding, so you should be able to update
> it easily enough.
Linaro binding? The DT is governed by a spec, we commit everything
upstream there. OTOH I still don't see what we need to put in there.
As we discussed this is a bus that can be used to scan devices.
Thanks
/Ilias
>
> Regards,
> Simon
next prev parent reply other threads:[~2022-09-16 20:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 9:37 [PATCH v4] tee: optee: rework TA bus scanning code Ilias Apalodimas
2022-09-06 13:37 ` Patrick DELAUNAY
2022-09-06 21:18 ` Simon Glass
2022-09-06 21:23 ` Ilias Apalodimas
2022-09-07 21:10 ` Simon Glass
2022-09-07 21:31 ` Ilias Apalodimas
2022-09-12 18:31 ` Simon Glass
2022-09-16 20:18 ` Ilias Apalodimas [this message]
[not found] <1ab0ea00-57c9-389c-ff0d-86defabba09e@foss.st.com>
2022-09-19 14:49 ` Patrick DELAUNAY
2022-09-22 8:51 ` Etienne Carriere
2022-09-22 10:14 ` Sumit Garg
2022-09-23 5:46 ` Etienne Carriere
2022-09-26 7:06 ` Sumit Garg
2022-09-28 7:55 ` Etienne Carriere
2022-09-22 11:27 ` Simon Glass
2022-09-22 16:06 ` Etienne Carriere
2022-09-22 18:15 ` Patrick DELAUNAY
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=YyTaGHpvRDOXOTgx@hera \
--to=ilias.apalodimas@linaro.org \
--cc=etienne.carriere@linaro.org \
--cc=jens.wiklander@linaro.org \
--cc=patrick.delaunay@foss.st.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.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.