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

[Dmitry Baryshkov]

On Wed, Mar 18, 2026 at 11:39:12AM +0100, Konrad Dybcio wrote:
> 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

I see only PAS calls.

-- 
With best wishes
Dmitry