mbox series

[v6,0/4] Introduce TEE bus driver framework

Message ID 1548740978-28495-1-git-send-email-sumit.garg@linaro.org (mailing list archive)
Headers show
Series Introduce TEE bus driver framework | expand

Message

Sumit Garg Jan. 29, 2019, 5:49 a.m. UTC
This series introduces a generic TEE bus driver concept for TEE based
kernel drivers which would like to communicate with TEE based devices/
services.

Patch #1 adds TEE bus concept where devices/services are identified via
Universally Unique Identifier (UUID) and drivers register a table of
device UUIDs which they can support. This concept also allows for device
enumeration to be specific to corresponding TEE implementation like
OP-TEE etc.

Patch #2 adds supp_nowait flag for non-blocking requests arising via
TEE internal client interface.

Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
provides a pseudo TA to enumerate TAs which can act as devices/services
for TEE bus.

Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
On ARM SoC's with TrustZone enabled, peripherals like entropy sources
might not be accessible to normal world (linux in this case) and rather
accessible to secure world (OP-TEE in this case) only. So this driver
aims to provides a generic interface to OP-TEE based random number
generator service.

Example case is Developerbox based on Socionext's Synquacer SoC [1]
which provides 7 thermal sensors accessible from secure world only which
could be used as entropy sources (thermal/measurement noise).

[1] https://www.96boards.org/product/developerbox/

Changes in v6:

1. Incorporate some nitpicks in patch #1 and #3.
2. Bundle all statics in a data structure in patch #4 and use dev_*
   instead of pr_*.
3. Add reviewed-by tags for patch #1, #2 and #3.

Changes in v5:

1. Add support in module device table for TEE bus devices.
2. Correct license for optee-rng module.

Changes in v4:

1. Use typedef instead of single member tee_client_device_id struct.
2. Incorporate TEE bus nitpicks.

Changes in v3:

1. Fixed bus error path in Patch #1.
2. Reversed order of Patch #2 and #3.
3. Fixed miscellaneous syntax comments and memory leak.
4. Added comments in Patch #2 for supp_nowait flag.

Changes in v2:

Based on review comments, the scope of this series has increased as
follows:

1. Added TEE bus driver framework.
2. Added OP-TEE based device enumeration.
3. Register optee-rng driver as TEE bus driver.
4. Removed DT dependency for optee-rng device UUID.
5. Added supp_nowait flag.

Sumit Garg (4):
  tee: add bus driver framework for TEE based devices
  tee: add supp_nowait flag in tee_context struct
  tee: optee: add TEE bus device enumeration support
  hwrng: add OP-TEE based rng driver

 MAINTAINERS                        |   5 +
 drivers/char/hw_random/Kconfig     |  15 ++
 drivers/char/hw_random/Makefile    |   1 +
 drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++
 drivers/tee/optee/Makefile         |   1 +
 drivers/tee/optee/core.c           |   4 +
 drivers/tee/optee/device.c         | 155 +++++++++++++++++++
 drivers/tee/optee/optee_private.h  |   3 +
 drivers/tee/optee/supp.c           |  10 +-
 drivers/tee/tee_core.c             |  67 ++++++++-
 include/linux/mod_devicetable.h    |   9 ++
 include/linux/tee_drv.h            |  38 ++++-
 scripts/mod/devicetable-offsets.c  |   3 +
 scripts/mod/file2alias.c           |  19 +++
 14 files changed, 622 insertions(+), 6 deletions(-)
 create mode 100644 drivers/char/hw_random/optee-rng.c
 create mode 100644 drivers/tee/optee/device.c

Comments

Jens Wiklander Jan. 31, 2019, 8:41 a.m. UTC | #1
Hi Matt and Herbert,

On Tue, Jan 29, 2019 at 11:19:34AM +0530, Sumit Garg wrote:
> This series introduces a generic TEE bus driver concept for TEE based
> kernel drivers which would like to communicate with TEE based devices/
> services.
> 
> Patch #1 adds TEE bus concept where devices/services are identified via
> Universally Unique Identifier (UUID) and drivers register a table of
> device UUIDs which they can support. This concept also allows for device
> enumeration to be specific to corresponding TEE implementation like
> OP-TEE etc.
> 
> Patch #2 adds supp_nowait flag for non-blocking requests arising via
> TEE internal client interface.
> 
> Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
> provides a pseudo TA to enumerate TAs which can act as devices/services
> for TEE bus.
> 
> Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
> On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> might not be accessible to normal world (linux in this case) and rather
> accessible to secure world (OP-TEE in this case) only. So this driver
> aims to provides a generic interface to OP-TEE based random number
> generator service.
> 
> Example case is Developerbox based on Socionext's Synquacer SoC [1]
> which provides 7 thermal sensors accessible from secure world only which
> could be used as entropy sources (thermal/measurement noise).
> 
> [1] https://www.96boards.org/product/developerbox/
> 
> Changes in v6:
> 
> 1. Incorporate some nitpicks in patch #1 and #3.
> 2. Bundle all statics in a data structure in patch #4 and use dev_*
>    instead of pr_*.
> 3. Add reviewed-by tags for patch #1, #2 and #3.
> 
> Changes in v5:
> 
> 1. Add support in module device table for TEE bus devices.
> 2. Correct license for optee-rng module.
> 
> Changes in v4:
> 
> 1. Use typedef instead of single member tee_client_device_id struct.
> 2. Incorporate TEE bus nitpicks.
> 
> Changes in v3:
> 
> 1. Fixed bus error path in Patch #1.
> 2. Reversed order of Patch #2 and #3.
> 3. Fixed miscellaneous syntax comments and memory leak.
> 4. Added comments in Patch #2 for supp_nowait flag.
> 
> Changes in v2:
> 
> Based on review comments, the scope of this series has increased as
> follows:
> 
> 1. Added TEE bus driver framework.
> 2. Added OP-TEE based device enumeration.
> 3. Register optee-rng driver as TEE bus driver.
> 4. Removed DT dependency for optee-rng device UUID.
> 5. Added supp_nowait flag.
> 
> Sumit Garg (4):
>   tee: add bus driver framework for TEE based devices
>   tee: add supp_nowait flag in tee_context struct
>   tee: optee: add TEE bus device enumeration support
>   hwrng: add OP-TEE based rng driver
> 
>  MAINTAINERS                        |   5 +
>  drivers/char/hw_random/Kconfig     |  15 ++
>  drivers/char/hw_random/Makefile    |   1 +
>  drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++
>  drivers/tee/optee/Makefile         |   1 +
>  drivers/tee/optee/core.c           |   4 +
>  drivers/tee/optee/device.c         | 155 +++++++++++++++++++
>  drivers/tee/optee/optee_private.h  |   3 +
>  drivers/tee/optee/supp.c           |  10 +-
>  drivers/tee/tee_core.c             |  67 ++++++++-
>  include/linux/mod_devicetable.h    |   9 ++
>  include/linux/tee_drv.h            |  38 ++++-
>  scripts/mod/devicetable-offsets.c  |   3 +
>  scripts/mod/file2alias.c           |  19 +++
>  14 files changed, 622 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/char/hw_random/optee-rng.c
>  create mode 100644 drivers/tee/optee/device.c
> 
> -- 
> 2.7.4
> 

I think this patch series is good now. It has received comments which
has been addressed and have also gathered a few R-B tags.

All patches but "hwrng: add OP-TEE based rng driver" covers what I
normally send pull requests to arm-soc for.

Matt, Herbert, are you fine with the patch
"hwrng: add OP-TEE based rng driver"?
If so, is it also OK if I take it via my tree which I then will include
in a pull request to arm-soc? An Acked-By tag would be nice to have.

Thanks,
Jens
Herbert Xu Jan. 31, 2019, 12:05 p.m. UTC | #2
On Thu, Jan 31, 2019 at 09:41:43AM +0100, Jens Wiklander wrote:
>
> I think this patch series is good now. It has received comments which
> has been addressed and have also gathered a few R-B tags.
> 
> All patches but "hwrng: add OP-TEE based rng driver" covers what I
> normally send pull requests to arm-soc for.
> 
> Matt, Herbert, are you fine with the patch
> "hwrng: add OP-TEE based rng driver"?
> If so, is it also OK if I take it via my tree which I then will include
> in a pull request to arm-soc? An Acked-By tag would be nice to have.

Sure you can add my ack-by:

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
Sumit Garg Jan. 31, 2019, 12:24 p.m. UTC | #3
On Thu, 31 Jan 2019 at 17:36, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Jan 31, 2019 at 09:41:43AM +0100, Jens Wiklander wrote:
> >
> > I think this patch series is good now. It has received comments which
> > has been addressed and have also gathered a few R-B tags.
> >
> > All patches but "hwrng: add OP-TEE based rng driver" covers what I
> > normally send pull requests to arm-soc for.
> >
> > Matt, Herbert, are you fine with the patch
> > "hwrng: add OP-TEE based rng driver"?
> > If so, is it also OK if I take it via my tree which I then will include
> > in a pull request to arm-soc? An Acked-By tag would be nice to have.
>
> Sure you can add my ack-by:
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
>

Thanks Jens and Herbert for providing acceptance to this patch-set.

-Sumit

> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Ard Biesheuvel Feb. 12, 2019, 11:05 a.m. UTC | #4
On Tue, 29 Jan 2019 at 06:50, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> This series introduces a generic TEE bus driver concept for TEE based
> kernel drivers which would like to communicate with TEE based devices/
> services.
>
> Patch #1 adds TEE bus concept where devices/services are identified via
> Universally Unique Identifier (UUID) and drivers register a table of
> device UUIDs which they can support. This concept also allows for device
> enumeration to be specific to corresponding TEE implementation like
> OP-TEE etc.
>
> Patch #2 adds supp_nowait flag for non-blocking requests arising via
> TEE internal client interface.
>
> Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
> provides a pseudo TA to enumerate TAs which can act as devices/services
> for TEE bus.
>
> Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
> On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> might not be accessible to normal world (linux in this case) and rather
> accessible to secure world (OP-TEE in this case) only. So this driver
> aims to provides a generic interface to OP-TEE based random number
> generator service.
>
> Example case is Developerbox based on Socionext's Synquacer SoC [1]
> which provides 7 thermal sensors accessible from secure world only which
> could be used as entropy sources (thermal/measurement noise).
>
> [1] https://www.96boards.org/product/developerbox/
>
> Changes in v6:
>
> 1. Incorporate some nitpicks in patch #1 and #3.
> 2. Bundle all statics in a data structure in patch #4 and use dev_*
>    instead of pr_*.
> 3. Add reviewed-by tags for patch #1, #2 and #3.
>
> Changes in v5:
>
> 1. Add support in module device table for TEE bus devices.
> 2. Correct license for optee-rng module.
>
> Changes in v4:
>
> 1. Use typedef instead of single member tee_client_device_id struct.
> 2. Incorporate TEE bus nitpicks.
>
> Changes in v3:
>
> 1. Fixed bus error path in Patch #1.
> 2. Reversed order of Patch #2 and #3.
> 3. Fixed miscellaneous syntax comments and memory leak.
> 4. Added comments in Patch #2 for supp_nowait flag.
>
> Changes in v2:
>
> Based on review comments, the scope of this series has increased as
> follows:
>
> 1. Added TEE bus driver framework.
> 2. Added OP-TEE based device enumeration.
> 3. Register optee-rng driver as TEE bus driver.
> 4. Removed DT dependency for optee-rng device UUID.
> 5. Added supp_nowait flag.
>
> Sumit Garg (4):
>   tee: add bus driver framework for TEE based devices
>   tee: add supp_nowait flag in tee_context struct
>   tee: optee: add TEE bus device enumeration support
>   hwrng: add OP-TEE based rng driver
>

For this series

Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

although I had to load optee.ko manually in order for the udev
autoload of optee_rng to trigger. Not sure where the discussion went
last time, but could we please add "linaro,optee-tz" as a DT modalias
to the optee.ko module in any case?

>  MAINTAINERS                        |   5 +
>  drivers/char/hw_random/Kconfig     |  15 ++
>  drivers/char/hw_random/Makefile    |   1 +
>  drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++
>  drivers/tee/optee/Makefile         |   1 +
>  drivers/tee/optee/core.c           |   4 +
>  drivers/tee/optee/device.c         | 155 +++++++++++++++++++
>  drivers/tee/optee/optee_private.h  |   3 +
>  drivers/tee/optee/supp.c           |  10 +-
>  drivers/tee/tee_core.c             |  67 ++++++++-
>  include/linux/mod_devicetable.h    |   9 ++
>  include/linux/tee_drv.h            |  38 ++++-
>  scripts/mod/devicetable-offsets.c  |   3 +
>  scripts/mod/file2alias.c           |  19 +++
>  14 files changed, 622 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/char/hw_random/optee-rng.c
>  create mode 100644 drivers/tee/optee/device.c
>
> --
> 2.7.4
>
Sumit Garg Feb. 12, 2019, 12:09 p.m. UTC | #5
On Tue, 12 Feb 2019 at 16:35, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Tue, 29 Jan 2019 at 06:50, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > This series introduces a generic TEE bus driver concept for TEE based
> > kernel drivers which would like to communicate with TEE based devices/
> > services.
> >
> > Patch #1 adds TEE bus concept where devices/services are identified via
> > Universally Unique Identifier (UUID) and drivers register a table of
> > device UUIDs which they can support. This concept also allows for device
> > enumeration to be specific to corresponding TEE implementation like
> > OP-TEE etc.
> >
> > Patch #2 adds supp_nowait flag for non-blocking requests arising via
> > TEE internal client interface.
> >
> > Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
> > provides a pseudo TA to enumerate TAs which can act as devices/services
> > for TEE bus.
> >
> > Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
> > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> > might not be accessible to normal world (linux in this case) and rather
> > accessible to secure world (OP-TEE in this case) only. So this driver
> > aims to provides a generic interface to OP-TEE based random number
> > generator service.
> >
> > Example case is Developerbox based on Socionext's Synquacer SoC [1]
> > which provides 7 thermal sensors accessible from secure world only which
> > could be used as entropy sources (thermal/measurement noise).
> >
> > [1] https://www.96boards.org/product/developerbox/
> >
> > Changes in v6:
> >
> > 1. Incorporate some nitpicks in patch #1 and #3.
> > 2. Bundle all statics in a data structure in patch #4 and use dev_*
> >    instead of pr_*.
> > 3. Add reviewed-by tags for patch #1, #2 and #3.
> >
> > Changes in v5:
> >
> > 1. Add support in module device table for TEE bus devices.
> > 2. Correct license for optee-rng module.
> >
> > Changes in v4:
> >
> > 1. Use typedef instead of single member tee_client_device_id struct.
> > 2. Incorporate TEE bus nitpicks.
> >
> > Changes in v3:
> >
> > 1. Fixed bus error path in Patch #1.
> > 2. Reversed order of Patch #2 and #3.
> > 3. Fixed miscellaneous syntax comments and memory leak.
> > 4. Added comments in Patch #2 for supp_nowait flag.
> >
> > Changes in v2:
> >
> > Based on review comments, the scope of this series has increased as
> > follows:
> >
> > 1. Added TEE bus driver framework.
> > 2. Added OP-TEE based device enumeration.
> > 3. Register optee-rng driver as TEE bus driver.
> > 4. Removed DT dependency for optee-rng device UUID.
> > 5. Added supp_nowait flag.
> >
> > Sumit Garg (4):
> >   tee: add bus driver framework for TEE based devices
> >   tee: add supp_nowait flag in tee_context struct
> >   tee: optee: add TEE bus device enumeration support
> >   hwrng: add OP-TEE based rng driver
> >
>
> For this series
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>

Thanks. BTW, Jens has created a GIT PULL[1] to incorporate this patch-set.

> although I had to load optee.ko manually in order for the udev
> autoload of optee_rng to trigger.

Did you built OP-TEE module as out-of-tree? OP-TEE by-default is
built-in kernel module as per following configs in default defconfig:

CONFIG_TEE=y
CONFIG_OPTEE=y

> Not sure where the discussion went
> last time, but could we please add "linaro,optee-tz" as a DT modalias
> to the optee.ko module in any case?
>

This change is already part of your RFC patch [2] and I agree to make
OP-TEE as platform driver.

[1] https://lkml.org/lkml/2019/2/4/104
[2] https://lkml.org/lkml/2018/12/27/196

-Sumit

> >  MAINTAINERS                        |   5 +
> >  drivers/char/hw_random/Kconfig     |  15 ++
> >  drivers/char/hw_random/Makefile    |   1 +
> >  drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++
> >  drivers/tee/optee/Makefile         |   1 +
> >  drivers/tee/optee/core.c           |   4 +
> >  drivers/tee/optee/device.c         | 155 +++++++++++++++++++
> >  drivers/tee/optee/optee_private.h  |   3 +
> >  drivers/tee/optee/supp.c           |  10 +-
> >  drivers/tee/tee_core.c             |  67 ++++++++-
> >  include/linux/mod_devicetable.h    |   9 ++
> >  include/linux/tee_drv.h            |  38 ++++-
> >  scripts/mod/devicetable-offsets.c  |   3 +
> >  scripts/mod/file2alias.c           |  19 +++
> >  14 files changed, 622 insertions(+), 6 deletions(-)
> >  create mode 100644 drivers/char/hw_random/optee-rng.c
> >  create mode 100644 drivers/tee/optee/device.c
> >
> > --
> > 2.7.4
> >
Ard Biesheuvel Feb. 12, 2019, 12:10 p.m. UTC | #6
On Tue, 12 Feb 2019 at 13:09, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Tue, 12 Feb 2019 at 16:35, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> > On Tue, 29 Jan 2019 at 06:50, Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > This series introduces a generic TEE bus driver concept for TEE based
> > > kernel drivers which would like to communicate with TEE based devices/
> > > services.
> > >
> > > Patch #1 adds TEE bus concept where devices/services are identified via
> > > Universally Unique Identifier (UUID) and drivers register a table of
> > > device UUIDs which they can support. This concept also allows for device
> > > enumeration to be specific to corresponding TEE implementation like
> > > OP-TEE etc.
> > >
> > > Patch #2 adds supp_nowait flag for non-blocking requests arising via
> > > TEE internal client interface.
> > >
> > > Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
> > > provides a pseudo TA to enumerate TAs which can act as devices/services
> > > for TEE bus.
> > >
> > > Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
> > > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> > > might not be accessible to normal world (linux in this case) and rather
> > > accessible to secure world (OP-TEE in this case) only. So this driver
> > > aims to provides a generic interface to OP-TEE based random number
> > > generator service.
> > >
> > > Example case is Developerbox based on Socionext's Synquacer SoC [1]
> > > which provides 7 thermal sensors accessible from secure world only which
> > > could be used as entropy sources (thermal/measurement noise).
> > >
> > > [1] https://www.96boards.org/product/developerbox/
> > >
> > > Changes in v6:
> > >
> > > 1. Incorporate some nitpicks in patch #1 and #3.
> > > 2. Bundle all statics in a data structure in patch #4 and use dev_*
> > >    instead of pr_*.
> > > 3. Add reviewed-by tags for patch #1, #2 and #3.
> > >
> > > Changes in v5:
> > >
> > > 1. Add support in module device table for TEE bus devices.
> > > 2. Correct license for optee-rng module.
> > >
> > > Changes in v4:
> > >
> > > 1. Use typedef instead of single member tee_client_device_id struct.
> > > 2. Incorporate TEE bus nitpicks.
> > >
> > > Changes in v3:
> > >
> > > 1. Fixed bus error path in Patch #1.
> > > 2. Reversed order of Patch #2 and #3.
> > > 3. Fixed miscellaneous syntax comments and memory leak.
> > > 4. Added comments in Patch #2 for supp_nowait flag.
> > >
> > > Changes in v2:
> > >
> > > Based on review comments, the scope of this series has increased as
> > > follows:
> > >
> > > 1. Added TEE bus driver framework.
> > > 2. Added OP-TEE based device enumeration.
> > > 3. Register optee-rng driver as TEE bus driver.
> > > 4. Removed DT dependency for optee-rng device UUID.
> > > 5. Added supp_nowait flag.
> > >
> > > Sumit Garg (4):
> > >   tee: add bus driver framework for TEE based devices
> > >   tee: add supp_nowait flag in tee_context struct
> > >   tee: optee: add TEE bus device enumeration support
> > >   hwrng: add OP-TEE based rng driver
> > >
> >
> > For this series
> >
> > Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
>
> Thanks. BTW, Jens has created a GIT PULL[1] to incorporate this patch-set.
>
> > although I had to load optee.ko manually in order for the udev
> > autoload of optee_rng to trigger.
>
> Did you built OP-TEE module as out-of-tree? OP-TEE by-default is
> built-in kernel module as per following configs in default defconfig:
>
> CONFIG_TEE=y
> CONFIG_OPTEE=y
>

Yes, but the distros will carry it as a module.

> > Not sure where the discussion went
> > last time, but could we please add "linaro,optee-tz" as a DT modalias
> > to the optee.ko module in any case?
> >
>
> This change is already part of your RFC patch [2] and I agree to make
> OP-TEE as platform driver.
>
> [1] https://lkml.org/lkml/2019/2/4/104
> [2] https://lkml.org/lkml/2018/12/27/196
>

Indeed, but iirc there was a question from Jens and I wasn't sure it
had been answered in the mean time.
Sumit Garg Feb. 12, 2019, 12:55 p.m. UTC | #7
On Tue, 12 Feb 2019 at 17:41, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Tue, 12 Feb 2019 at 13:09, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > On Tue, 12 Feb 2019 at 16:35, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > >
> > > On Tue, 29 Jan 2019 at 06:50, Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > This series introduces a generic TEE bus driver concept for TEE based
> > > > kernel drivers which would like to communicate with TEE based devices/
> > > > services.
> > > >
> > > > Patch #1 adds TEE bus concept where devices/services are identified via
> > > > Universally Unique Identifier (UUID) and drivers register a table of
> > > > device UUIDs which they can support. This concept also allows for device
> > > > enumeration to be specific to corresponding TEE implementation like
> > > > OP-TEE etc.
> > > >
> > > > Patch #2 adds supp_nowait flag for non-blocking requests arising via
> > > > TEE internal client interface.
> > > >
> > > > Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE
> > > > provides a pseudo TA to enumerate TAs which can act as devices/services
> > > > for TEE bus.
> > > >
> > > > Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver.
> > > > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> > > > might not be accessible to normal world (linux in this case) and rather
> > > > accessible to secure world (OP-TEE in this case) only. So this driver
> > > > aims to provides a generic interface to OP-TEE based random number
> > > > generator service.
> > > >
> > > > Example case is Developerbox based on Socionext's Synquacer SoC [1]
> > > > which provides 7 thermal sensors accessible from secure world only which
> > > > could be used as entropy sources (thermal/measurement noise).
> > > >
> > > > [1] https://www.96boards.org/product/developerbox/
> > > >
> > > > Changes in v6:
> > > >
> > > > 1. Incorporate some nitpicks in patch #1 and #3.
> > > > 2. Bundle all statics in a data structure in patch #4 and use dev_*
> > > >    instead of pr_*.
> > > > 3. Add reviewed-by tags for patch #1, #2 and #3.
> > > >
> > > > Changes in v5:
> > > >
> > > > 1. Add support in module device table for TEE bus devices.
> > > > 2. Correct license for optee-rng module.
> > > >
> > > > Changes in v4:
> > > >
> > > > 1. Use typedef instead of single member tee_client_device_id struct.
> > > > 2. Incorporate TEE bus nitpicks.
> > > >
> > > > Changes in v3:
> > > >
> > > > 1. Fixed bus error path in Patch #1.
> > > > 2. Reversed order of Patch #2 and #3.
> > > > 3. Fixed miscellaneous syntax comments and memory leak.
> > > > 4. Added comments in Patch #2 for supp_nowait flag.
> > > >
> > > > Changes in v2:
> > > >
> > > > Based on review comments, the scope of this series has increased as
> > > > follows:
> > > >
> > > > 1. Added TEE bus driver framework.
> > > > 2. Added OP-TEE based device enumeration.
> > > > 3. Register optee-rng driver as TEE bus driver.
> > > > 4. Removed DT dependency for optee-rng device UUID.
> > > > 5. Added supp_nowait flag.
> > > >
> > > > Sumit Garg (4):
> > > >   tee: add bus driver framework for TEE based devices
> > > >   tee: add supp_nowait flag in tee_context struct
> > > >   tee: optee: add TEE bus device enumeration support
> > > >   hwrng: add OP-TEE based rng driver
> > > >
> > >
> > > For this series
> > >
> > > Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > >
> >
> > Thanks. BTW, Jens has created a GIT PULL[1] to incorporate this patch-set.
> >
> > > although I had to load optee.ko manually in order for the udev
> > > autoload of optee_rng to trigger.
> >
> > Did you built OP-TEE module as out-of-tree? OP-TEE by-default is
> > built-in kernel module as per following configs in default defconfig:
> >
> > CONFIG_TEE=y
> > CONFIG_OPTEE=y
> >
>
> Yes, but the distros will carry it as a module.
>

Hmm, I see. So in this case OP-TEE module needs to be loaded manually
due to missing modalias for udev autoload.

-Sumit

> > > Not sure where the discussion went
> > > last time, but could we please add "linaro,optee-tz" as a DT modalias
> > > to the optee.ko module in any case?
> > >
> >
> > This change is already part of your RFC patch [2] and I agree to make
> > OP-TEE as platform driver.
> >
> > [1] https://lkml.org/lkml/2019/2/4/104
> > [2] https://lkml.org/lkml/2018/12/27/196
> >
>
> Indeed, but iirc there was a question from Jens and I wasn't sure it
> had been answered in the mean time.