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

[Konrad Dybcio]

On 3/18/26 11:38 AM, Dmitry Baryshkov wrote:
> On Wed, Mar 18, 2026 at 10:33:28AM +0100, Konrad Dybcio wrote:
>> On 3/16/26 3:25 PM, Dmitry Baryshkov wrote:
>>> On Mon, Mar 16, 2026 at 10:39:09AM +0100, Konrad Dybcio wrote:
>>>> On 3/13/26 3:48 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, Mar 13, 2026 at 12:59:46PM +0100, 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:
>>>>>>
>>>>>>> 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
>>>>>
>>>>> qcom_scm_pas_is_available() ?
>>>>
>>>> This comes back to either having to wait for the interconnect provider
>>>> anyway, or allowing the ICC-enhanced calls to take place before they that
>>>> happens, stripping us of the benefits.
>>>
>>> Yes. However this way only the PAS users will have to wait (i.e.
>>> remoteprocs, venus, IPA, etc.). All the basic providers would be able to
>>> probe.
>>
>> Do you then envision a separate qcom_scm_pil_is_available()?
> 
> Which calls would it guard?

pil/pas/whatever.. auth_and_reset(), probably

Konrad