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.
Remove them from the scm device to unblock the user.
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -308,8 +308,7 @@ eud_in: endpoint {
firmware {
scm: scm {
compatible = "qcom,scm-x1e80100", "qcom,scm";
- interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
- &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ /* TODO: add interconnects */
qcom,dload-mode = <&tcsr 0x19000>;
};
--
2.34.1On 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
So fix drivers.
> results in NULL pointer dereference for the users of SCM device
> driver APIs, such as PDC driver.
>
> Remove them from the scm device to unblock the user.
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -308,8 +308,7 @@ eud_in: endpoint {
> firmware {
> scm: scm {
> compatible = "qcom,scm-x1e80100", "qcom,scm";
> - interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> - &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> + /* TODO: add interconnects */
NAK, interconnects were there already. So after applying your patch I
can just revert it immediately solving the TODO.
Best regards,
Krzysztof
On 3/13/2026 7:26 PM, Krzysztof Kozlowski 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
>
> So fix drivers.
Yes, will address in v2.
>
>> results in NULL pointer dereference for the users of SCM device
>> driver APIs, such as PDC driver.
>>
>> Remove them from the scm device to unblock the user.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -308,8 +308,7 @@ eud_in: endpoint {
>> firmware {
>> scm: scm {
>> compatible = "qcom,scm-x1e80100", "qcom,scm";
>> - interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
>> - &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>> + /* TODO: add interconnects */
>
> NAK, interconnects were there already. So after applying your patch I
> can just revert it immediately solving the TODO.
Yes, this change will be dropped from v2 and instead will be using qcom_scm_is_available()
to handle the dependencies.
Thanks,
Maulik
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.
>
> Remove them from the scm device to unblock the user.
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -308,8 +308,7 @@ eud_in: endpoint {
> firmware {
> scm: scm {
> compatible = "qcom,scm-x1e80100", "qcom,scm";
> - interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> - &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> + /* TODO: add interconnects */
Somebody will try to fix this TODO, reverting this patch. Let's find a
better way to handle it (which would also fit other platforms).
Originaly this was proposed by Sibi ([1]) to speed up PAS
authentication. Other platforms require RPM or GCC clocks to let the
firmware access crypto core.
One of the (stupid) ideas would be to add a separate SCM (child?) device
which would be used for crypto-related SCM calls. I'd like to point out
that currently we bump those clocks or NoC bandwidth, but at the same
time we don't vote on the CX rail. I'm not sure of the firmware handles
that somehow or not.
[1] https://lore.kernel.org/all/1653289258-17699-1-git-send-email-quic_sibis@quicinc.com/
> qcom,dload-mode = <&tcsr 0x19000>;
> };
>
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
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,
int qcom_scm_ready(void)
{
if (__scm == NULL || __scm->dev == NULL)
return -EPROBE_DEFER;
return 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_ready);
This is inline with what cmd-db does today with cmd_db_ready() API.
(drivers/soc/qcom/cmd-db.c).
>
>>
>> Remove them from the scm device to unblock the user.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -308,8 +308,7 @@ eud_in: endpoint {
>> firmware {
>> scm: scm {
>> compatible = "qcom,scm-x1e80100", "qcom,scm";
>> - interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
>> - &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>> + /* TODO: add interconnects */
>
> Somebody will try to fix this TODO, reverting this patch. Let's find a
> better way to handle it (which would also fit other platforms).
> Originaly this was proposed by Sibi ([1]) to speed up PAS
> authentication. Other platforms require RPM or GCC clocks to let the
> firmware access crypto core.
>
> One of the (stupid) ideas would be to add a separate SCM (child?) device
> which would be used for crypto-related SCM calls. I'd like to point out
> that currently we bump those clocks or NoC bandwidth, but at the same
> time we don't vote on the CX rail. I'm not sure of the firmware handles
> that somehow or not.
Nice catch, AFAIK firmware don't handle voting for CX rail during SCM call.
>
> [1] https://lore.kernel.org/all/1653289258-17699-1-git-send-email-quic_sibis@quicinc.com/
yes, I had already seen this,
So remoteproc PAS driver gets performance benefit with crypto vote and interesting choice was
made to place it from SCM driver. It was evaluated and considered reasonable one at that time,
pasting from [2],
The clocking needs for the CE relates to the SCM and not the remoteproc, and it's in line with
the management of CE clocks from the SCM driver.
With my limited understanding of remoteproc, SCM and crypto,
- A crypto vote would no way bump up the performance of CPU jumping from/to non-secure and secure world.
(actual "path" of SCM driver).
if remoteproc requires the crypto vote for image validation/authentication then remoteproc should
place the vote for crypto path before invoking SCM APIs, SCM don't really use this vote for itself.
SCM driver though today adds/removes vote within remoteproc APIs keeping vote placement limited
to remoteproc usage only.
- Firmware could have put the crypto vote if firmware is doing image validation/authentication
after the SCM call lands in firmware and remove it before returning to non-secure world.
clearly not a choice now to update firmware.
- I see crypto device too places same vote (at least on x1e) so i must be missing something and
both SCM and crypto device vote are needed here. I was thinking if remoteproc should route the
SCM call via crypto driver (which would places the required crypto vote) and crypto driver
should then invoke the crypto related SMC calls.
crypto: crypto@1dfa000 {
compatible = "qcom,x1e80100-qce", "qcom,sm8150-qce", "qcom,qce";
..
interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
};
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.
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.
d) Add separate SCM child device (with interconnects) under SoC.
[2] https://lore.kernel.org/all/Yr0Os5TOITY7f0Wk@builder.lan/
Thanks,
Maulik
On Fri, Mar 13, 2026 at 03:42:32PM +0530, 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,
qcom_scm_is_available() ?
>
> int qcom_scm_ready(void)
> {
> if (__scm == NULL || __scm->dev == NULL)
> return -EPROBE_DEFER;
> return 0;
> }
> EXPORT_SYMBOL_GPL(qcom_scm_ready);
>
> This is inline with what cmd-db does today with cmd_db_ready() API.
> (drivers/soc/qcom/cmd-db.c).
>
> >
> >>
> >> Remove them from the scm device to unblock the user.
> >>
> >> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/hamoa.dtsi | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> >> index d7596ccf63b90a8a002ad6e77c0fb2c1b32ec9c8..ebecf43e0d462c431540257e299e3ace054901fd 100644
> >> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> >> @@ -308,8 +308,7 @@ eud_in: endpoint {
> >> firmware {
> >> scm: scm {
> >> compatible = "qcom,scm-x1e80100", "qcom,scm";
> >> - interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> >> - &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> >> + /* TODO: add interconnects */
> >
> > Somebody will try to fix this TODO, reverting this patch. Let's find a
> > better way to handle it (which would also fit other platforms).
> > Originaly this was proposed by Sibi ([1]) to speed up PAS
> > authentication. Other platforms require RPM or GCC clocks to let the
> > firmware access crypto core.
> >
> > One of the (stupid) ideas would be to add a separate SCM (child?) device
> > which would be used for crypto-related SCM calls. I'd like to point out
> > that currently we bump those clocks or NoC bandwidth, but at the same
> > time we don't vote on the CX rail. I'm not sure of the firmware handles
> > that somehow or not.
>
> Nice catch, AFAIK firmware don't handle voting for CX rail during SCM call.
>
> >
> > [1] https://lore.kernel.org/all/1653289258-17699-1-git-send-email-quic_sibis@quicinc.com/
>
> yes, I had already seen this,
>
> So remoteproc PAS driver gets performance benefit with crypto vote and interesting choice was
> made to place it from SCM driver. It was evaluated and considered reasonable one at that time,
> pasting from [2],
> The clocking needs for the CE relates to the SCM and not the remoteproc, and it's in line with
> the management of CE clocks from the SCM driver.
I agree that those clocks must be managed, but I think it was a hack to
reuse SCM's iface / bus clocks for crypto. Originally, *I suppose* were
added for very old platforms which had separate DAYTONA NoC clock, most
likely controlling access to some of the backing hardware, but not
necessarily crypto hardware.
>
> With my limited understanding of remoteproc, SCM and crypto,
>
> - A crypto vote would no way bump up the performance of CPU jumping from/to non-secure and secure world.
> (actual "path" of SCM driver).
>
> if remoteproc requires the crypto vote for image validation/authentication then remoteproc should
> place the vote for crypto path before invoking SCM APIs, SCM don't really use this vote for itself.
> SCM driver though today adds/removes vote within remoteproc APIs keeping vote placement limited
> to remoteproc usage only.
Looking at the code, I'd assume that once we start testing HDCP we'd
perform the same for the HDCP-related calls. The problem is that this
kind of management also doesn't seem to belong to the remoteproc driver:
it doesn't know and it should be of no concern for it if the firmware
uses crypto behind its back or not.
> - Firmware could have put the crypto vote if firmware is doing image validation/authentication
> after the SCM call lands in firmware and remove it before returning to non-secure world.
> clearly not a choice now to update firmware.
>
> - I see crypto device too places same vote (at least on x1e) so i must be missing something and
> both SCM and crypto device vote are needed here. I was thinking if remoteproc should route the
> SCM call via crypto driver (which would places the required crypto vote) and crypto driver
> should then invoke the crypto related SMC calls.
I think, this also looks like a hammer plumbing. The use of crypto
device for those calls is a firmware implementation detail.
>
> crypto: crypto@1dfa000 {
> compatible = "qcom,x1e80100-qce", "qcom,sm8150-qce", "qcom,qce";
> ..
> interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> };
>
> 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.
We already have qcom_scm_is_available().
> b) Move interconnects from SCM to remoteproc PAS driver for all devices
> Take the vote before invoking SCM API and release after return.
> 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.
> d) Add separate SCM child device (with interconnects) under SoC.
This is going to be my preference, but I'm ready to listen for other
opinions.
>
> [2] https://lore.kernel.org/all/Yr0Os5TOITY7f0Wk@builder.lan/
>
> Thanks,
> Maulik
--
With best wishes
Dmitry
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
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
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() ? -- With best wishes Dmitry
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. Konrad
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. -- With best wishes Dmitry
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()? Konrad
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
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
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
© 2016 - 2026 Red Hat, Inc.