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

[Dmitry Baryshkov]

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?

> 
> Konrad

-- 
With best wishes
Dmitry