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

[Konrad Dybcio]

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()


> 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)

> 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

> d) Add separate SCM child device (with interconnects) under SoC.

We'd then have to probe it as an aux device or something, which would
either delay the probing of SCM, or introduce the need to ping-pong for
PAS availability between the API provider and consumer, since some calls
work perfectly fine without the ICC path, while others could really use
it

Konrad