linux-kernel - Re: [PATCH v2] soc: qcom: ice: Stop probe deferring once ICE isn't detected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <edc737f7-0148-105c-8121-4be0d758647c@oss.qualcomm.com>
Date: Tue, 3 Feb 2026 12:20:56 +0530
From: Neeraj Soni <neeraj.soni@....qualcomm.com>
To: Manivannan Sadhasivam <mani@...nel.org>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Sumit Garg <sumit.garg@...nel.org>, linux-arm-msm@...r.kernel.org,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        andersson@...nel.org, konradybcio@...nel.org, robh+dt@...nel.org,
        abelvesa@...nel.org, linux-kernel@...r.kernel.org,
        Sumit Garg <sumit.garg@....qualcomm.com>
Subject: Re: [PATCH v2] soc: qcom: ice: Stop probe deferring once ICE isn't
 detected



On 2/2/2026 4:25 PM, Manivannan Sadhasivam wrote:
> On Mon, Feb 02, 2026 at 11:51:51AM +0100, Konrad Dybcio wrote:
>> On 2/2/26 9:25 AM, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@....qualcomm.com>
>>>
>>> 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 stop 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@....qualcomm.com>
>>> ---
>>>
>>> Changes in v2:
>>> - Keep the probe deferring intact but stop it once it's know ICE SCM
>>>   calls aren't supported by the TZ firmware.
>>>
>>>  drivers/soc/qcom/ice.c | 11 +++++++----
>>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
>>> index b203bc685cad..5a630c9010ee 100644
>>> --- a/drivers/soc/qcom/ice.c
>>> +++ b/drivers/soc/qcom/ice.c
>>> @@ -559,7 +559,7 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
>>>  
>>>  	if (!qcom_scm_ice_available()) {
>>>  		dev_warn(dev, "ICE SCM interface not found\n");
>>> -		return NULL;
>>> +		return ERR_PTR(-EOPNOTSUPP);
>>>  	}
>>>  
>>>  	engine = devm_kzalloc(dev, sizeof(*engine), GFP_KERNEL);
>>> @@ -648,11 +648,14 @@ static struct qcom_ice *of_qcom_ice_get(struct device *dev)
>>>  	}
>>>  
>>>  	ice = platform_get_drvdata(pdev);
>>> -	if (!ice) {
>>> +	if (IS_ERR_OR_NULL(ice)) {
>>>  		dev_err(dev, "Cannot get ice instance from %s\n",
>>>  			dev_name(&pdev->dev));
>>>  		platform_device_put(pdev);
>>> -		return ERR_PTR(-EPROBE_DEFER);
>>> +		if (PTR_ERR(ice) == -EOPNOTSUPP)
>>> +			return NULL;
>>
>> The consumer drivers check specifically for -EOPNOTSUPP, let's
>> just return that
>>
>>> +		else
>>> +			return ERR_PTR(-EPROBE_DEFER);
>>>  	}
>>>  
>>>  	link = device_link_add(dev, &pdev->dev, DL_FLAG_AUTOREMOVE_SUPPLIER);
>>> @@ -726,7 +729,7 @@ static int qcom_ice_probe(struct platform_device *pdev)
>>>  	}
>>>  
>>>  	engine = qcom_ice_create(&pdev->dev, base);
>>> -	if (IS_ERR(engine))
>>> +	if (IS_ERR(engine) && PTR_ERR(engine) != -EOPNOTSUPP)
>>>  		return PTR_ERR(engine);
>>
>> This essentially says "probe succeeded, device not operational",
>> I have mixed feelings.. That said I'm not sure about the lifecycle
>> of a platform_device, i.e. can we set the drvdata and return an error
>> in .probe anyway?
>>
> 
> No. Let's remove the probe() altogether and expose this driver as a pure
> library.
> 
The ICE driver already acts as a library for legacy DT case where consumer device provides 'ice'
reg range. It was made dedicated platform driver as ICE is a common IP for UFS and SDCC. See here:
https://lore.kernel.org/all/20230407105029.2274111-4-abel.vesa@linaro.org/
I think it will be better if we resolve the race between probe() and *of_qcom_ice_get().

> - Mani
> Regards
Neeraj