Re: [PATCH 1/5] firmware: qcom: Add a generic ICE service

[Konrad Dybcio]

On 10/24/26 3:46 PM, Harshal Dev wrote:
> Hi Konrad,
> 
> On 22-10-2026 01:15 pm, Konrad Dybcio wrote:
>> On 10/21/26 5:43 PM, Harshal Dev wrote:
>>> Qualcomm platforms such as the IQ-9075 EVK now boot with both QTEE and
>>> OPTEE. However, the Qualcomm Inline Crypto Engine (ICE) driver
>>> currently only makes SCM calls into QTEE. With the arrival of ICE
>>> support on OPTEE for Qualcomm platforms, there is a need for a generic
>>> layer which re-directs the call to the correct TEE at runtime.
>>>
>>> Add a generic ICE service which acts as a common layer with different
>>> TEE backends plugged in whether it's an SCM implementation or a proper
>>> TEE bus based implementation (such as for OPTEE).
>>>
>>> Signed-off-by: Harshal Dev <harshal.dev@xxxxxxxxxxxxxxxx>
>>> ---
>>
>> [...]
>>
>>> +bool qcom_ice_svc_ops_registered(void)
>>> +{
>>> +	/*
>>> +	 * The barrier for ops_ptr is intended to synchronize the data stores
>>> +	 * for the ops data structure when client drivers are in parallel
>>> +	 * checking for ICE service availability.
>>> +	 */
>>> +	return !!smp_load_acquire(&ops_ptr);
>>> +}
>>> +EXPORT_SYMBOL_GPL(qcom_ice_svc_ops_registered);
>>> +
>>> +bool qcom_ice_svc_available(void)
>>> +{
>>> +	if (!ops_ptr)
>>
>> Should this also be a barrier read?
>>
> 
> It does not need to be. The client (ICE driver in this case) should always
> call qcom_ice_svc_ops_registered() first before calling any other function
> exported by this ICE service. That's the contract. If that is followed then
> ops_ptr always contains its actual value (either NULL, or pointing to the
> TEE or SCM driver back-end).
> 
> We could use a barrier here, but then we should use a barrier in every other
> exported function here as well, which feels like an overkill.
> 
> Let me know if any concerns.

I think you're right

Konrad