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
