Re: [PATCH 1/5] arm64: dts: qcom: x1e80100: Remove interconnect from SCM device

[Maulik Shah (mkshah)]

On 3/13/2026 5:29 PM, Konrad Dybcio wrote:
> On 3/13/26 11:12 AM, Maulik Shah (mkshah) wrote:
>>
>>
>> On 3/13/2026 7:41 AM, Dmitry Baryshkov wrote:
>>> On Thu, Mar 12, 2026 at 09:26:35PM +0530, Maulik Shah wrote:
>>>> Interconnect from SCM device are optional and were added to get
>>>> additional performance benefit. These nodes however delays the
>>>> SCM firmware device probe due to dependency on interconnect and
>>>> results in NULL pointer dereference for the users of SCM device
>>>> driver APIs, such as PDC driver.
>>>
>>> This sounds like a bug in the PDC driver. It should reject being probed
>>> before SCM is available.
>>
>> The SCM driver provides no way to check if its ready or not to decide to reject/defer the probe.
>> A new API like below would be needed here,
> 
> There is, qcom_scm_is_available()

Thanks, i will use this API in v2 to defer the probe and drop this patch.
Deferring still delays PDC probe significantly but it would unblock this series.

> 
> 
>> Let me know any preferences from below options or any other.
>>
>> a) Add the API like qcom_scm_ready(), this has been tested and works fine.
>> b) Move interconnects from SCM to remoteproc PAS driver for all devices
>>    Take the vote before invoking SCM API and release after return.
> 
> I think this is not the right decision. The crypto path is only necessary,
> because cryptographic checks must be carried out in the TZ in order to
> (dis)allow a certain firmware binary. This is not a characteristic of the
> remoteprocs themselves, as with a non-prudent TZ, the firmware loading
> would amount to a memcpy() (and some SMMU/XPU configs via reg writes)

This does not seem to be a characteristic of SCM either.

Loading and booting the firmware is part of remoteproc and not SCM.
(Documentation/devicetree/bindings/remoteproc/*)
The votes required to (dis)allow loading them faster (such as crpyto) should also fall
under remoteproc otherwise any driver requiring SCM API (for other purposes) would put
the burden of placing votes on SCM driver?

> 
>> c) Remove the interconnects from SCM and rely on crypto driver already
>>    placing the vote, Route the remote proc to SCM call via crypto API,
>>    This would ensure crpyto is being used and it would have placed the required vote.
> 
> I think this would make things even worse, because instead of waiting on
> the interconnect driver, we'd now have to wait on the interconnect driver,
> the clock driver and the crypto driver

okay, i was just wondering if crypto vote can somehow be leveraged so SCM do not need
to place the vote.

Thanks,
Maulik