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

[Harshal Dev <harshal.dev@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
> 
> [...]
> 
>> +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.

Regards,
Harshal
 
> Konrad