On 23/03/2026 15:26, Konrad Dybcio wrote:
This pattern has been carried from the PAS API contract among kernel clients and the SCM PAS service earlier. The clients don't hold a reference to the PAS data like underlying platform or TEE device etc. Hence the need to have a global data pointer to hold reference to the ops data structure registered by drivers having different lifetime of devices. Also, the PAS APIs can be called from very different client driver contexts.
Surely, avoiding global data is always better given a better alternative is there. Do you have any better alternative proposal here?
Why it cannot be part of the context?
Look at your API, e.g.: qcom_pas_init_image(). It takes struct qcom_pas_context which should contain the ops.
This would make the client have to select the ops. The whole point is to avoid that, since the client has no clue (and is supposed not to have any).
Yeah, I see. The problem is that this patchset just keeps growing the singletons so except existing 'struct qcom_scm *__scm' in qcom_scm.c, this one brings at least three new: 'ops_ptr', 'qcom_pas_ops_scm' and 'qcom_pas_ops_tee'.
I don't think you need all four in total, but only one which will hold whatever pointers are necessary.
Best regards, Krzysztof