* [PATCH] tee: optee: rework TA bus scanning code
@ 2022-08-23 8:11 Ilias Apalodimas
2022-08-26 8:46 ` Jens Wiklander
0 siblings, 1 reply; 4+ messages in thread
From: Ilias Apalodimas @ 2022-08-23 8:11 UTC (permalink / raw)
To: u-boot
Cc: etienne.carriere, Ilias Apalodimas, Jens Wiklander, Patrick Delaunay
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.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
drivers/tee/optee/core.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index a89d62aaf0b3..48a9b59171cb 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -31,6 +31,20 @@ struct optee_pdata {
optee_invoke_fn *invoke_fn;
};
+static const struct {
+ const char *drv_name;
+ const char *dev_name;
+} optee_bus_probe[] = {
+#ifdef CONFIG_RNG_OPTEE
+ { "optee-rng", "optee-rng" },
+#endif
+#ifdef CONFIG_TPM2_FTPM_TEE
+ { "ftpm-tee", "ftpm-tee" },
+#endif
+};
+
+#define MAX_TEE_BUS_DEV_COUNT ARRAY_SIZE(optee_bus_probe)
+
struct rpc_param {
u32 a0;
u32 a1;
@@ -643,7 +657,7 @@ static int optee_probe(struct udevice *dev)
struct optee_pdata *pdata = dev_get_plat(dev);
u32 sec_caps;
struct udevice *child;
- int ret;
+ int ret, i;
if (!is_optee_api(pdata->invoke_fn)) {
dev_err(dev, "OP-TEE api uid mismatch\n");
@@ -672,8 +686,10 @@ static int optee_probe(struct udevice *dev)
* in U-Boot, the discovery of TA on the TEE bus is not supported:
* only bind the drivers associated to the supported OP-TEE TA
*/
- if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
- ret = device_bind_driver(dev, "optee-rng", "optee-rng", &child);
+
+ for (i = 0; i < MAX_TEE_BUS_DEV_COUNT; i++) {
+ ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
+ optee_bus_probe[i].dev_name, &child);
if (ret)
return ret;
}
--
2.34.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] tee: optee: rework TA bus scanning code
2022-08-23 8:11 [PATCH] tee: optee: rework TA bus scanning code Ilias Apalodimas
@ 2022-08-26 8:46 ` Jens Wiklander
2022-08-26 9:07 ` Etienne Carriere
0 siblings, 1 reply; 4+ messages in thread
From: Jens Wiklander @ 2022-08-26 8:46 UTC (permalink / raw)
To: Ilias Apalodimas; +Cc: u-boot, etienne.carriere, Patrick Delaunay
On Tue, Aug 23, 2022 at 10:11 AM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> 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.
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
> drivers/tee/optee/core.c | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index a89d62aaf0b3..48a9b59171cb 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -31,6 +31,20 @@ struct optee_pdata {
> optee_invoke_fn *invoke_fn;
> };
>
> +static const struct {
> + const char *drv_name;
> + const char *dev_name;
> +} optee_bus_probe[] = {
> +#ifdef CONFIG_RNG_OPTEE
> + { "optee-rng", "optee-rng" },
> +#endif
> +#ifdef CONFIG_TPM2_FTPM_TEE
> + { "ftpm-tee", "ftpm-tee" },
> +#endif
> +};
> +
> +#define MAX_TEE_BUS_DEV_COUNT ARRAY_SIZE(optee_bus_probe)
> +
> struct rpc_param {
> u32 a0;
> u32 a1;
> @@ -643,7 +657,7 @@ static int optee_probe(struct udevice *dev)
> struct optee_pdata *pdata = dev_get_plat(dev);
> u32 sec_caps;
> struct udevice *child;
> - int ret;
> + int ret, i;
>
> if (!is_optee_api(pdata->invoke_fn)) {
> dev_err(dev, "OP-TEE api uid mismatch\n");
> @@ -672,8 +686,10 @@ static int optee_probe(struct udevice *dev)
> * in U-Boot, the discovery of TA on the TEE bus is not supported:
> * only bind the drivers associated to the supported OP-TEE TA
> */
> - if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> - ret = device_bind_driver(dev, "optee-rng", "optee-rng", &child);
> +
> + for (i = 0; i < MAX_TEE_BUS_DEV_COUNT; i++) {
> + ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> + optee_bus_probe[i].dev_name, &child);
> if (ret)
> return ret;
I wonder which behaviour is most useful. Disable OP-TEE support
completely if there's some error when binding dependent drivers or to
just complain a bit but continue.
Cheers,
Jens
>
> }
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] tee: optee: rework TA bus scanning code
2022-08-26 8:46 ` Jens Wiklander
@ 2022-08-26 9:07 ` Etienne Carriere
2022-08-26 9:19 ` Ilias Apalodimas
0 siblings, 1 reply; 4+ messages in thread
From: Etienne Carriere @ 2022-08-26 9:07 UTC (permalink / raw)
To: Jens Wiklander; +Cc: Ilias Apalodimas, u-boot, Patrick Delaunay
Hello Ilias, Jens,
On Fri, 26 Aug 2022 at 10:46, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> On Tue, Aug 23, 2022 at 10:11 AM Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > 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.
> >
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > ---
> > drivers/tee/optee/core.c | 22 +++++++++++++++++++---
> > 1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > index a89d62aaf0b3..48a9b59171cb 100644
> > --- a/drivers/tee/optee/core.c
> > +++ b/drivers/tee/optee/core.c
> > @@ -31,6 +31,20 @@ struct optee_pdata {
> > optee_invoke_fn *invoke_fn;
> > };
> >
> > +static const struct {
> > + const char *drv_name;
> > + const char *dev_name;
> > +} optee_bus_probe[] = {
> > +#ifdef CONFIG_RNG_OPTEE
> > + { "optee-rng", "optee-rng" },
> > +#endif
> > +#ifdef CONFIG_TPM2_FTPM_TEE
> > + { "ftpm-tee", "ftpm-tee" },
> > +#endif
> > +};
> > +
> > +#define MAX_TEE_BUS_DEV_COUNT ARRAY_SIZE(optee_bus_probe)
> > +
> > struct rpc_param {
> > u32 a0;
> > u32 a1;
> > @@ -643,7 +657,7 @@ static int optee_probe(struct udevice *dev)
> > struct optee_pdata *pdata = dev_get_plat(dev);
> > u32 sec_caps;
> > struct udevice *child;
> > - int ret;
> > + int ret, i;
> >
> > if (!is_optee_api(pdata->invoke_fn)) {
> > dev_err(dev, "OP-TEE api uid mismatch\n");
> > @@ -672,8 +686,10 @@ static int optee_probe(struct udevice *dev)
> > * in U-Boot, the discovery of TA on the TEE bus is not supported:
> > * only bind the drivers associated to the supported OP-TEE TA
> > */
> > - if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> > - ret = device_bind_driver(dev, "optee-rng", "optee-rng", &child);
> > +
> > + for (i = 0; i < MAX_TEE_BUS_DEV_COUNT; i++) {
I would use ARRAY_SIZE(optee_bus_probe) straight here. Macro
indirection is not really useful imho.
> > + ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> > + optee_bus_probe[i].dev_name, &child);
> > if (ret)
> > return ret;
>
> I wonder which behaviour is most useful. Disable OP-TEE support
> completely if there's some error when binding dependent drivers or to
> just complain a bit but continue.
I agree with you, this should better print the status and proceed with
the next driver.
There are other occurrences of such behaviour in U-Boot.
Br,
etienne
>
> Cheers,
> Jens
>
>
> >
> > }
> > --
> > 2.34.1
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] tee: optee: rework TA bus scanning code
2022-08-26 9:07 ` Etienne Carriere
@ 2022-08-26 9:19 ` Ilias Apalodimas
0 siblings, 0 replies; 4+ messages in thread
From: Ilias Apalodimas @ 2022-08-26 9:19 UTC (permalink / raw)
To: Etienne Carriere; +Cc: Jens Wiklander, u-boot, Patrick Delaunay
Hey Etienne, Jens
[...]
> > > - if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> > > - ret = device_bind_driver(dev, "optee-rng", "optee-rng", &child);
> > > +
> > > + for (i = 0; i < MAX_TEE_BUS_DEV_COUNT; i++) {
>
> I would use ARRAY_SIZE(optee_bus_probe) straight here. Macro
> indirection is not really useful imho.
Sure
>
> > > + ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> > > + optee_bus_probe[i].dev_name, &child);
> > > if (ret)
> > > return ret;
> >
> > I wonder which behaviour is most useful. Disable OP-TEE support
> > completely if there's some error when binding dependent drivers or to
> > just complain a bit but continue.
>
> I agree with you, this should better print the status and proceed with
> the next driver.
> There are other occurrences of such behaviour in U-Boot.
I also agree, however this changes the behaviour of *existing* code, which
I tried to avoid. Since you both think it's better, I'll just add a
log_err() on v2 and continue.
Thanks
/Ilias
>
> Br,
> etienne
>
>
> >
> > Cheers,
> > Jens
> >
> >
> > >
> > > }
> > > --
> > > 2.34.1
> > >
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-08-26 9:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-23 8:11 [PATCH] tee: optee: rework TA bus scanning code Ilias Apalodimas
2022-08-26 8:46 ` Jens Wiklander
2022-08-26 9:07 ` Etienne Carriere
2022-08-26 9:19 ` Ilias Apalodimas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).