summaryrefslogtreecommitdiff
path: root/arch/xtensa/include
diff options
context:
space:
mode:
authorIgor Opaniuk <igor.opaniuk@linaro.org>2018-12-04 14:37:19 +0200
committerTom Rini <trini@konsulko.com>2018-12-15 11:49:19 -0500
commit8b1312662b3b1748c3d5f8a30bc6f9ca72879c7a (patch)
tree5f88098a5a02a5160278434976ad3de73ebcc2ab /arch/xtensa/include
parent8fc26fce41592175ae004514e431e68a9dd60671 (diff)
tee: change return code for REE FS supplicant cmd
If OP-TEE core is compiled with support of REE FS and RPMB at the same time (CFG_RPMB_FS ?= y; CFG_RPMB_FS ?= y), and persistent storage API is used with TEE_STORAGE_PRIVATE storage id, it will lead to TA panic. E/TC:? 0 TA panicked with code 0xffff0009 ..... E/TC:? 0 Call stack: E/TC:? 0 0x000000004002f2f8 TEE_OpenPersistentObject at lib/libutee/tee_api_objects.c:422 In this particular case TEE_ERROR_STORAGE_NOT_AVAILABLE is more suitable than TEE_ERROR_NOT_IMPLEMENTED, as it provides to a TA a possibility to handle this error code [1]. >From GPD TEE Internal Core specification [2]: TEE_ERROR_STORAGE_NOT_AVAILABLE - if the persistent object is stored in a storage area which is currently inaccessible. It may be associated with the device but unplugged, busy, or inaccessible for some other reason. [1]: https://github.com/OP-TEE/optee_os/blob/94db01ef448d1e552161c2d861d57a5f8bda0cc0/lib/libutee/tee_api_objects.c#L419 [2]: https://globalplatform.org/wp-content/uploads/2018/06/GPD_TEE_Internal_Core_API_Specification_v1.1.2.50_PublicReview.pdf Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Diffstat (limited to 'arch/xtensa/include')
0 files changed, 0 insertions, 0 deletions