From: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
To: Manivannan Sadhasivam <mani@kernel.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Sumit Garg <sumit.garg@kernel.org>,
linux-arm-msm@vger.kernel.org,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
andersson@kernel.org, konradybcio@kernel.org, robh+dt@kernel.org,
abelvesa@kernel.org, linux-kernel@vger.kernel.org,
Sumit Garg <sumit.garg@oss.qualcomm.com>
Subject: Re: [PATCH v2] soc: qcom: ice: Stop probe deferring once ICE isn't detected
Date: Tue, 3 Feb 2026 12:20:56 +0530 [thread overview]
Message-ID: <edc737f7-0148-105c-8121-4be0d758647c@oss.qualcomm.com> (raw)
In-Reply-To: <frq54ya6nounvn3rmqklbkrhobds3dznpaxkcnlmcjr7gtbkgu@qi5xyb4o4sno>
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@oss.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@oss.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
next prev parent reply other threads:[~2026-02-03 6:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 8:25 Sumit Garg
2026-02-02 10:51 ` Konrad Dybcio
2026-02-02 10:55 ` Manivannan Sadhasivam
2026-02-03 6:50 ` Neeraj Soni [this message]
2026-02-03 12:22 ` Manivannan Sadhasivam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edc737f7-0148-105c-8121-4be0d758647c@oss.qualcomm.com \
--to=neeraj.soni@oss.qualcomm.com \
--cc=abelvesa@kernel.org \
--cc=andersson@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mani@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sumit.garg@kernel.org \
--cc=sumit.garg@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®