[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFA6WYOizPWj+DhWB0OcmApqSyTANTbr+eNWycMqYt-GpLz3xw@mail.gmail.com>
Date: Wed, 2 Jan 2019 10:34:52 +0530
From: Sumit Garg <sumit.garg@...aro.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Jens Wiklander <jens.wiklander@...aro.org>,
Graeme Gregory <graeme.gregory@...aro.org>,
Jerome Forissier <jerome.forissier@...aro.org>
Subject: Re: [RFC PATCH 0/2] allow optee to be exposed on ACPI systems
On Fri, 28 Dec 2018 at 00:31, Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>
> Similar to how OP-TEE is exposed as a pseudo device under /firmware/optee
> on DT systems, permit OP-TEE presence to be exposed via a device object
> in the ACPI namespace. This makes it possible to model the OP-TEE interface
> as a platform device gets instantiated automatically both on DT and ACPI
> systems, and implement the driver as a platform driver that is able to
> use the generic device properties API to access the 'method' attribute
> as well as potential future extensions to the binding that introduce
> new attributes.
>
> What remains to be discussed is how to expose OP-TEE pseudo devices,
> e.g., Sumit's RNG implementation on SynQuacer which we would like to
> bind a Linux driver to.
>
> Cc: Jens Wiklander <jens.wiklander@...aro.org>
> Cc: Sumit Garg <sumit.garg@...aro.org>
> Cc: Graeme Gregory <graeme.gregory@...aro.org>
> Cc: Jerome Forissier <jerome.forissier@...aro.org>
>
> Ard Biesheuvel (2):
> optee: model OP-TEE as a platform device/driver
> optee: add ACPI support
>
> drivers/tee/optee/core.c | 94 +++++++++-----------
> 1 file changed, 41 insertions(+), 53 deletions(-)
>
Looks good to me.
Acked-by: Sumit Garg <sumit.garg@...aro.org>
> --
> 2.19.2
>
Powered by blists - more mailing lists