Re: [PATCH] soc: qcom: ice: Avoid probe deferring for un-supported ICE feature

[Manivannan Sadhasivam]

On Fri, Jan 30, 2026 at 10:59:18AM +0100, Konrad Dybcio wrote:
> On 1/30/26 10:52 AM, Sumit Garg wrote:
> > On Fri, Jan 30, 2026 at 10:34:26AM +0100, Konrad Dybcio wrote:
> >> On 1/30/26 10:11 AM, Sumit Garg wrote:
> >>> From: Sumit Garg <sumit.garg@xxxxxxxxxxxxxxxx>
> >>>
> >>> ICE related SCM calls may not be supported in every TZ environment like
> >>> OP-TEE or a no-TZ environment too. So let's try to avoid probe deferring
> >>> when it's known that ICE feature isn't supported.
> >>>
> >>> This problem only came to notice after the inline encryption drivers were
> >>> enabled in the arm64 defconfig by: commit 5f37788adedd ("arm64: defconfig:
> >>> Enable SCSI UFS Crypto and Block Inline encryption drivers").
> >>>
> >>> Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver")
> >>> Signed-off-by: Sumit Garg <sumit.garg@xxxxxxxxxxxxxxxx>
> >>> ---
> >>>  drivers/soc/qcom/ice.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> >>> index b203bc685cad..ab9586b8caf5 100644
> >>> --- a/drivers/soc/qcom/ice.c
> >>> +++ b/drivers/soc/qcom/ice.c
> >>> @@ -652,7 +652,7 @@ static struct qcom_ice *of_qcom_ice_get(struct device *dev)
> >>>  		dev_err(dev, "Cannot get ice instance from %s\n",
> >>>  			dev_name(&pdev->dev));
> >>>  		platform_device_put(pdev);
> >>> -		return ERR_PTR(-EPROBE_DEFER);
> >>> +		return NULL;
> >>
> >> Wouldn't this wreck the "actually need to defer" case, i.e.
> >>
> >>
> >> qcom,ufs probes first
> >>   calls devm_of_qcom_ice_get()
> >>     "ice" reg is missing, non-legacy case
> >>       qcom,ice is absent (not yet probed)
> >>         return NULL
> >>
> >> ...
> >>
> >> qcom,ice probes
> >>
> >> ?
> > 
> > Since qcom,ufs depends on qcom,ice via a phandle, so isn't the probe
> > orderering automatically taken care off? Or that isn't the case here?
> 
> No, that's guaranteed by devlink only with certain properties.
> 
> In this case though, I think it could make sense to add it to the
> "suppliers" list in drivers/of/property.c.
> 
> I don't know if vendors adding their custom properties there is a
> pattern that +Rob will be happy about though..
> 

Yeah. I initially considered adding 'qcom,ice' as a supplier, but was not sure
of its reception. So decided not to pursue this path.

I think there is no point in exposing the ICE driver as a platform driver and
allow it to race against the of_qcom_ice_get() API.

- Mani

-- 
மணிவண்ணன் சதாசிவம்