Hi,
On Thu, Mar 12, 2015 at 01:56:17PM -0400, Javier González wrote: [...]
+/**
- TEE_IOC_CMD - pass a command to the specific TEE driver
- Takes tee_cmd_data struct which is passed to the specific TEE driver.
- */
+#define TEE_IOC_CMD _TEE_IOR(1, struct tee_cmd_data)
Here, I would like to add TEE_IOC_TASK for stateless calls to the TEE.
TEE_IOC_CMD is stateless in the generic driver, it's up to the specific driver to add a state concept. Some requests through TEE_IOC_CMD could be handled without a state. Doesn't that cover what you're after?
There will be requests into secure world that will not go via this generic driver. PSCI is one example. On ARMv8 PSCI is handled in ARM-TF at EL3, but on ARMv7 it will probably be handled by the secure OS. If we compare with what's defined in SMC Calling Convention I think this driver will only be dealing with stuff that falls in the SMC ranges for Trusted Application and Trusted OS calls. The generic driver will not try to enforce that in any way since it doesn't even know what an SMC is.
If you all agree that TEE_IOC_LOAD_TS and TEE_IOC_GET_TS_LIST should be left for future revisions, it is OK. I think though that having the discussion about how OP_TEE could support this is necessary.
I think that TEE_IOC_LOAD_TS at this stage is something for the specific driver to deal with, in OP-TEE we're doing it with tee-supplicant.
I'm not sure that TEE_IOC_GET_TS_LIST is needed. As Joakim pointed out earlier, a Trusted Service/Application is identified with a uuid which is just a sequence of byte with no particular meaning.
Suppose that a client know that it would like to communicate with either uuid1 or uuid2, it could just try to do that and if the uuid isn't available an error will be returned. If the client would request a list of uuids first and discover that none where available, what would be the difference?
-- Regards, Jens