mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-09-21 12:11:49 +08:00
50709576d8
Add a separate documentation directory for TEE subsystem since it is a standalone subsystem which already offers devices consumed by multiple different subsystem drivers. Split overall TEE subsystem documentation modularly where: - The userspace API has been moved to Documentation/userspace-api/tee.rst. - The driver API has been moved to Documentation/driver-api/tee.rst. - The first module covers the overview of TEE subsystem. - The further modules are dedicated to different TEE implementations like: - OP-TEE - AMD-TEE - and so on for future TEE implementation support. Acked-by: Rijo Thomas <Rijo-john.Thomas@amd.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20231128072352.866859-1-sumit.garg@linaro.org
67 lines
2.0 KiB
ReStructuredText
67 lines
2.0 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
===============================================
|
|
TEE (Trusted Execution Environment) driver API
|
|
===============================================
|
|
|
|
Kernel provides a TEE bus infrastructure where a Trusted Application is
|
|
represented as a device identified via Universally Unique Identifier (UUID) and
|
|
client drivers register a table of supported device UUIDs.
|
|
|
|
TEE bus infrastructure registers following APIs:
|
|
|
|
match():
|
|
iterates over the client driver UUID table to find a corresponding
|
|
match for device UUID. If a match is found, then this particular device is
|
|
probed via corresponding probe API registered by the client driver. This
|
|
process happens whenever a device or a client driver is registered with TEE
|
|
bus.
|
|
|
|
uevent():
|
|
notifies user-space (udev) whenever a new device is registered on
|
|
TEE bus for auto-loading of modularized client drivers.
|
|
|
|
TEE bus device enumeration is specific to underlying TEE implementation, so it
|
|
is left open for TEE drivers to provide corresponding implementation.
|
|
|
|
Then TEE client driver can talk to a matched Trusted Application using APIs
|
|
listed in include/linux/tee_drv.h.
|
|
|
|
TEE client driver example
|
|
-------------------------
|
|
|
|
Suppose a TEE client driver needs to communicate with a Trusted Application
|
|
having UUID: ``ac6a4085-0e82-4c33-bf98-8eb8e118b6c2``, so driver registration
|
|
snippet would look like::
|
|
|
|
static const struct tee_client_device_id client_id_table[] = {
|
|
{UUID_INIT(0xac6a4085, 0x0e82, 0x4c33,
|
|
0xbf, 0x98, 0x8e, 0xb8, 0xe1, 0x18, 0xb6, 0xc2)},
|
|
{}
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(tee, client_id_table);
|
|
|
|
static struct tee_client_driver client_driver = {
|
|
.id_table = client_id_table,
|
|
.driver = {
|
|
.name = DRIVER_NAME,
|
|
.bus = &tee_bus_type,
|
|
.probe = client_probe,
|
|
.remove = client_remove,
|
|
},
|
|
};
|
|
|
|
static int __init client_init(void)
|
|
{
|
|
return driver_register(&client_driver.driver);
|
|
}
|
|
|
|
static void __exit client_exit(void)
|
|
{
|
|
driver_unregister(&client_driver.driver);
|
|
}
|
|
|
|
module_init(client_init);
|
|
module_exit(client_exit);
|