Re: [PATCH 0/5] Add support for a TEE agnostic Inline Crypto Engine service

[Harshal Dev]

Hi Eric,

On 25-10-2026 12:26 am, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 09:13:06PM +0530, Harshal Dev wrote:
>> This patch series adds a generic ICE service which provides TEE agnostic
>> APIs
> 
> There is already an ICE driver: drivers/soc/qcom/ice.c.  If it needs to
> do different things on different platforms, then it should be updated to
> do so.

Agreed, however this series does not intend to replace the ICE driver. It is
only meant to make the driver's calls into the ARM TEE firmware OS agnostic
of whether the platform boots with QTEE or OP-TEE. The ICE driver should not
do different things on different platforms, it should do exactly the same
things, however the TEE firmware calls should not be tied to QTEE as they
have been until now. 

> Adding a separate middleware module underneath it, with the ICE
> driver as its sole user, is unnecessary complexity that will just cause
> problems.
>

By moving the TEE call re-direction to a separate middleware we are ensuring
that we only touch the 9-10 lines in the driver which depend on the TEE firmware.
Merging this functionality in the ICE driver would substantially increases
the total file size.

> In fact the middleware module is called qcom_ice.ko, which is the exact
> same name as the ICE driver.  That's broken, as it's a name collision.

I agree with this point, I will re-name it to qcom_ice_tee_svc.ko, Hopefully
that will help with the name collision.

> I think the fact they have the same name hints pretty strongly that the
> functionality should just be incorporated into the existing qcom_ice.ko.
>

I beg to differ here. The ICE driver programs the non-secure hardware
interfaces of the ICE hardware. The ICE service this series introduces
re-directs ICE driver's calls into the TEE firmware to the correct firmware
booted on the platform. I believe these two are very orthogonal functionalities.
> AFAICT, this series also breaks boot on platforms without ICE firmware
> support, due to indefinite EPROBE_DEFER.  Choosing a simpler design
> would help avoid issues like that.

As per my understanding, all versions of the Qualcomm ICE hardware depend
on the TEE firmware to program certain aspects of the hardware. In-fact
a portion of the hardware interfaces of ICE are secure-software only
programmable. So we don't have any platform where ICE works without TEE
firmware support. This is why probe always defers if this check fails:
https://elixir.bootlin.com/linux/v7.3/source/drivers/soc/qcom/ice.c#L568

Appreciate your valuable time and suggestions here Eric. Do let me know if
any further thoughts.

Regards,
Harshal
> 
> - Eric