[PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

Document new property arm,poll-transport, which sets all SCMI operation into
poll mode. This is meant to work around uncooperative SCP implementations,
which do not generate completion interrupts. This applies primarily on mbox
based implementations, but does also cover SMC and VirtIO ones.

With this property set, such implementations which do not generate interrupts
can be interacted with, until they are fixed to generate interrupts properly.

Note that, because the original base protocol exchange also requires some
sort of completion mechanism, it is not possible to query SCMI itself for
this property and it must be described in DT. While this does look a bit
like policy, the SCMI provider is part of the hardware, hence DT.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <florian.fainelli@broadcom.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: arm-scmi@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
---
 Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index be817fd9cc34b..b53754a318ea1 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -146,6 +146,13 @@ properties:
       this platform. If set, the value should be non-zero.
     minimum: 1
 
+  arm,poll-transport:
+    type: boolean
+    description:
+      An optional property which unconditionally forces polling in all transports.
+      This is mainly mean to work around uncooperative SCP, which does not generate
+      completion interrupts.
+
   arm,smc-id:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-- 
2.51.0

[PATCH 2/2] firmware: arm_scmi: Implement arm,poll-transport property

[Marek Vasut]

Implement new property arm,poll-transport, which sets all SCMI operation into
poll mode. This is meant to work around uncooperative SCP implementations,
which do not generate completion interrupts. This applies primarily on mbox
based implementations, but does also cover SMC and VirtIO ones.

With this property set, such implementations which do not generate interrupts
can be interacted with, until they are fixed to generate interrupts properly.

The SMC transport is modified such, that it ignores interrupts described in
DT in case this property is set. This is an edge case, where the SMC transport
may use this property to ignore broken interrupts too.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <florian.fainelli@broadcom.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: arm-scmi@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/firmware/arm_scmi/common.h         |  4 ++++
 drivers/firmware/arm_scmi/driver.c         |  4 ++++
 drivers/firmware/arm_scmi/transports/smc.c | 20 +++++++++++---------
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
index 7c35c95fddbaf..7c9617d080a02 100644
--- a/drivers/firmware/arm_scmi/common.h
+++ b/drivers/firmware/arm_scmi/common.h
@@ -235,6 +235,9 @@ struct scmi_transport_ops {
  *		      to have an execution latency lesser-equal to the threshold
  *		      should be considered for atomic mode operation: such
  *		      decision is finally left up to the SCMI drivers.
+ * @no_completion_irq: Flag to indicate that this transport has no completion
+ *		       interrupt and has to be polled. This is similar to the
+ *		       force_polling below, except this is set via DT property.
  * @force_polling: Flag to force this whole transport to use SCMI core polling
  *		   mechanism instead of completion interrupts even if available.
  * @sync_cmds_completed_on_ret: Flag to indicate that the transport assures
@@ -254,6 +257,7 @@ struct scmi_desc {
 	int max_msg;
 	int max_msg_size;
 	unsigned int atomic_threshold;
+	bool no_completion_irq;
 	const bool force_polling;
 	const bool sync_cmds_completed_on_ret;
 	const bool atomic_enabled;
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 5caa9191a8d1a..1079c84608a2c 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -2677,6 +2677,7 @@ static int scmi_chan_setup(struct scmi_info *info, struct device_node *of_node,
 	cinfo->is_p2a = !tx;
 	cinfo->rx_timeout_ms = info->desc->max_rx_timeout_ms;
 	cinfo->max_msg_size = info->desc->max_msg_size;
+	cinfo->no_completion_irq = info->desc->no_completion_irq;
 
 	/* Create a unique name for this transport device */
 	snprintf(name, 32, "__scmi_transport_device_%s_%02X",
@@ -3092,6 +3093,9 @@ static const struct scmi_desc *scmi_transport_setup(struct device *dev)
 	if (ret && ret != -EINVAL)
 		dev_err(dev, "Malformed arm,max-msg DT property.\n");
 
+	trans->desc.no_completion_irq = of_property_read_bool(dev->of_node,
+							      "arm,poll-transport");
+
 	dev_info(dev,
 		 "SCMI max-rx-timeout: %dms / max-msg-size: %dbytes / max-msg: %d\n",
 		 trans->desc.max_rx_timeout_ms, trans->desc.max_msg_size,
diff --git a/drivers/firmware/arm_scmi/transports/smc.c b/drivers/firmware/arm_scmi/transports/smc.c
index 21abb571e4f2f..85bfab650f100 100644
--- a/drivers/firmware/arm_scmi/transports/smc.c
+++ b/drivers/firmware/arm_scmi/transports/smc.c
@@ -177,16 +177,18 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo, struct device *dev,
 	 * completion of a message is signaled by an interrupt rather than by
 	 * the return of the SMC call.
 	 */
-	scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
-	if (scmi_info->irq > 0) {
-		ret = request_irq(scmi_info->irq, smc_msg_done_isr,
-				  IRQF_NO_SUSPEND, dev_name(dev), scmi_info);
-		if (ret) {
-			dev_err(dev, "failed to setup SCMI smc irq\n");
-			return ret;
+	if (!cinfo->no_completion_irq) {
+		scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
+		if (scmi_info->irq > 0) {
+			ret = request_irq(scmi_info->irq, smc_msg_done_isr,
+					  IRQF_NO_SUSPEND, dev_name(dev), scmi_info);
+			if (ret) {
+				dev_err(dev, "failed to setup SCMI smc irq\n");
+				return ret;
+			}
+		} else {
+			cinfo->no_completion_irq = true;
 		}
-	} else {
-		cinfo->no_completion_irq = true;
 	}
 
 	scmi_info->func_id = func_id;
-- 
2.51.0

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Geert Uytterhoeven]

Hi Marek,

On Thu, 23 Oct 2025 at 14:37, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Document new property arm,poll-transport, which sets all SCMI operation into
> poll mode. This is meant to work around uncooperative SCP implementations,
> which do not generate completion interrupts. This applies primarily on mbox
> based implementations, but does also cover SMC and VirtIO ones.
>
> With this property set, such implementations which do not generate interrupts
> can be interacted with, until they are fixed to generate interrupts properly.
>
> Note that, because the original base protocol exchange also requires some
> sort of completion mechanism, it is not possible to query SCMI itself for
> this property and it must be described in DT. While this does look a bit
> like policy, the SCMI provider is part of the hardware, hence DT.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -146,6 +146,13 @@ properties:
>        this platform. If set, the value should be non-zero.
>      minimum: 1
>
> +  arm,poll-transport:
> +    type: boolean
> +    description:
> +      An optional property which unconditionally forces polling in all transports.
> +      This is mainly mean to work around uncooperative SCP, which does not generate

meant

> +      completion interrupts.
> +
>    arm,smc-id:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      description:

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 3:07 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hello Geert,

> On Thu, 23 Oct 2025 at 14:37, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Document new property arm,poll-transport, which sets all SCMI operation into
>> poll mode. This is meant to work around uncooperative SCP implementations,
>> which do not generate completion interrupts. This applies primarily on mbox
>> based implementations, but does also cover SMC and VirtIO ones.
>>
>> With this property set, such implementations which do not generate interrupts
>> can be interacted with, until they are fixed to generate interrupts properly.
>>
>> Note that, because the original base protocol exchange also requires some
>> sort of completion mechanism, it is not possible to query SCMI itself for
>> this property and it must be described in DT. While this does look a bit
>> like policy, the SCMI provider is part of the hardware, hence DT.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> 
> Thanks for your patch!
> 
>> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>> @@ -146,6 +146,13 @@ properties:
>>         this platform. If set, the value should be non-zero.
>>       minimum: 1
>>
>> +  arm,poll-transport:
>> +    type: boolean
>> +    description:
>> +      An optional property which unconditionally forces polling in all transports.
>> +      This is mainly mean to work around uncooperative SCP, which does not generate
> 
> meant
Fixed locally for potential V2, thanks.

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
> Document new property arm,poll-transport, which sets all SCMI operation into
> poll mode. This is meant to work around uncooperative SCP implementations,
> which do not generate completion interrupts. This applies primarily on mbox
> based implementations, but does also cover SMC and VirtIO ones.
> 
> With this property set, such implementations which do not generate interrupts
> can be interacted with, until they are fixed to generate interrupts properly.
> 
> Note that, because the original base protocol exchange also requires some
> sort of completion mechanism, it is not possible to query SCMI itself for
> this property and it must be described in DT. While this does look a bit
> like policy, the SCMI provider is part of the hardware, hence DT.
> 
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Cristian Marussi <cristian.marussi@arm.com>
> Cc: Florian Fainelli <florian.fainelli@broadcom.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: arm-scmi@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index be817fd9cc34b..b53754a318ea1 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -146,6 +146,13 @@ properties:
>        this platform. If set, the value should be non-zero.
>      minimum: 1
>  
> +  arm,poll-transport:
> +    type: boolean
> +    description:
> +      An optional property which unconditionally forces polling in all transports.
> +      This is mainly mean to work around uncooperative SCP, which does not generate
> +      completion interrupts.
> +

Could you please clarify which platform and transport this change pertains to?

Introducing a property that enforces unconditional polling across all
platforms is not ideal - particularly if this is intended as a workaround
for a platform- or firmware- specific issue. Such implementations often get
replicated across platforms without addressing the root cause, leading to
wider inconsistencies.

It would be preferable to scope this behavior using the platform’s compatible
string. This approach ensures the workaround is applied only to the affected
platform and prevents it from being inadvertently enabled elsewhere, unless
another platform intentionally uses the same compatible string (which seems
unlikely).

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 3:16 PM, Sudeep Holla wrote:

Hello Sudeep,

>> +  arm,poll-transport:
>> +    type: boolean
>> +    description:
>> +      An optional property which unconditionally forces polling in all transports.
>> +      This is mainly mean to work around uncooperative SCP, which does not generate
>> +      completion interrupts.
>> +
> 
> Could you please clarify which platform and transport this change pertains to?

Renesas X5H with older SCP firmware , accessible via mailbox.

> Introducing a property that enforces unconditional polling across all
> platforms is not ideal - particularly if this is intended as a workaround
> for a platform- or firmware- specific issue. Such implementations often get
> replicated across platforms without addressing the root cause, leading to
> wider inconsistencies.

The root cause is being addressed already, this is meant to keep the 
older SCP version operable.

> It would be preferable to scope this behavior using the platform’s compatible
> string. This approach ensures the workaround is applied only to the affected
> platform and prevents it from being inadvertently enabled elsewhere, unless
> another platform intentionally uses the same compatible string (which seems
> unlikely).

This is not platform-specific issue. SCMI provider which fails to 
generate interrupts can appear on any platform, using either transport, 
that is why I made the property generic.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Cristian Marussi]

On Thu, Oct 23, 2025 at 03:42:02PM +0200, Marek Vasut wrote:
> On 10/23/25 3:16 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,

Hi Marek,

> 
> > > +  arm,poll-transport:
> > > +    type: boolean
> > > +    description:
> > > +      An optional property which unconditionally forces polling in all transports.
> > > +      This is mainly mean to work around uncooperative SCP, which does not generate
> > > +      completion interrupts.
> > > +
> > 
> > Could you please clarify which platform and transport this change pertains to?
> 
> Renesas X5H with older SCP firmware , accessible via mailbox.
> 
> > Introducing a property that enforces unconditional polling across all
> > platforms is not ideal - particularly if this is intended as a workaround
> > for a platform- or firmware- specific issue. Such implementations often get
> > replicated across platforms without addressing the root cause, leading to
> > wider inconsistencies.
> 
> The root cause is being addressed already, this is meant to keep the older
> SCP version operable.
> 

If this is the case, at first I would have tempted to say why not use the SCMI
Quirk framework (with needed changes/evolutions), BUT then I realized that being
the Quirk to be applied on the transport there is no way to gather SCMI
Vendor info and versions from the platform, so you would have to match on the
compatible, which is essentially similar approach of having a new DT
prop...just less flexible so I understand the need of your new-prop approach...

...BUT...(maybe a weird idea)...what if we think about enabling:

 - one Quirk EARLY-ON based on the current potentially affected compatibles
   with such a quirk forcing polling ONLY for the BASE Protocol SCMI queries
   so that the SCMI core can gather Vendor Info and versions in any case..
   (this would need the Quirk frmwk to be evolved to support such
    'early-quirks' based on compatibles only)

 - a second regular Quirk, filtered by the just retrieved Vendor INFO and FW
   version to finally decide if the system needs force-polling to be really
   enabled for all the following messages...

... this was you dint even need to ship any new DT

> > It would be preferable to scope this behavior using the platform’s compatible
> > string. This approach ensures the workaround is applied only to the affected
> > platform and prevents it from being inadvertently enabled elsewhere, unless
> > another platform intentionally uses the same compatible string (which seems
> > unlikely).
> 
> This is not platform-specific issue. SCMI provider which fails to generate
> interrupts can appear on any platform, using either transport, that is why I
> made the property generic.
> 

So the deployment scenario would be to update new machines with a fully
working SCP FW with completion-IRQ while updating ONLY the DTBs with the
new force-polling property in the older machines with the older
poll-only SCP fw ? (to understand)

Thanks,
Cristian

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 4:30 PM, Cristian Marussi wrote:

Hello Cristian,

>>>> +  arm,poll-transport:
>>>> +    type: boolean
>>>> +    description:
>>>> +      An optional property which unconditionally forces polling in all transports.
>>>> +      This is mainly mean to work around uncooperative SCP, which does not generate
>>>> +      completion interrupts.
>>>> +
>>>
>>> Could you please clarify which platform and transport this change pertains to?
>>
>> Renesas X5H with older SCP firmware , accessible via mailbox.
>>
>>> Introducing a property that enforces unconditional polling across all
>>> platforms is not ideal - particularly if this is intended as a workaround
>>> for a platform- or firmware- specific issue. Such implementations often get
>>> replicated across platforms without addressing the root cause, leading to
>>> wider inconsistencies.
>>
>> The root cause is being addressed already, this is meant to keep the older
>> SCP version operable.
>>
> 
> If this is the case, at first I would have tempted to say why not use the SCMI
> Quirk framework (with needed changes/evolutions), BUT then I realized that being
> the Quirk to be applied on the transport there is no way to gather SCMI
> Vendor info and versions from the platform, so you would have to match on the
> compatible, which is essentially similar approach of having a new DT
> prop...just less flexible so I understand the need of your new-prop approach...

Yes, that.

> ...BUT...(maybe a weird idea)...what if we think about enabling:
> 
>   - one Quirk EARLY-ON based on the current potentially affected compatibles

The current compatible string is "arm,scmi" . You would need a custom 
compatible for this early quirk, and this makes it not generic again.

>     with such a quirk forcing polling ONLY for the BASE Protocol SCMI queries
>     so that the SCMI core can gather Vendor Info and versions in any case..
>     (this would need the Quirk frmwk to be evolved to support such
>      'early-quirks' based on compatibles only)
> 
>   - a second regular Quirk, filtered by the just retrieved Vendor INFO and FW
>     version to finally decide if the system needs force-polling to be really
>     enabled for all the following messages...
> 
> ... this was you dint even need to ship any new DT

Maybe this is a bit too complicated and not very generic ?

I also tried to do this using quirks at first, but I couldn't find a way 
which I would like, it was always convoluted and ugly code.

>>> It would be preferable to scope this behavior using the platform’s compatible
>>> string. This approach ensures the workaround is applied only to the affected
>>> platform and prevents it from being inadvertently enabled elsewhere, unless
>>> another platform intentionally uses the same compatible string (which seems
>>> unlikely).
>>
>> This is not platform-specific issue. SCMI provider which fails to generate
>> interrupts can appear on any platform, using either transport, that is why I
>> made the property generic.
>>
> 
> So the deployment scenario would be to update new machines with a fully
> working SCP FW with completion-IRQ while updating ONLY the DTBs with the
> new force-polling property in the older machines with the older
> poll-only SCP fw ? (to understand)

Yes, correct.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Thu, Oct 23, 2025 at 03:42:02PM +0200, Marek Vasut wrote:
> On 10/23/25 3:16 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > +  arm,poll-transport:
> > > +    type: boolean
> > > +    description:
> > > +      An optional property which unconditionally forces polling in all transports.
> > > +      This is mainly mean to work around uncooperative SCP, which does not generate
> > > +      completion interrupts.
> > > +
> > 
> > Could you please clarify which platform and transport this change pertains to?
> 
> Renesas X5H with older SCP firmware , accessible via mailbox.
> 

So mailbox transport it is. Thanks for the info.

> > Introducing a property that enforces unconditional polling across all
> > platforms is not ideal - particularly if this is intended as a workaround
> > for a platform- or firmware- specific issue. Such implementations often get
> > replicated across platforms without addressing the root cause, leading to
> > wider inconsistencies.
> 
> The root cause is being addressed already, this is meant to keep the older
> SCP version operable.
> 

Good to know.

> > It would be preferable to scope this behavior using the platform’s compatible
> > string. This approach ensures the workaround is applied only to the affected
> > platform and prevents it from being inadvertently enabled elsewhere, unless
> > another platform intentionally uses the same compatible string (which seems
> > unlikely).
> 
> This is not platform-specific issue. SCMI provider which fails to generate
> interrupts can appear on any platform, using either transport, that is why I
> made the property generic.
> 

Good point, but ideally this is property of the transport itself. For example,
what does this "arm,poll-transport" can possibly mean for SMC/Optee transport ?

I understand this is a valid request, just not sure if this is the right way
to solve( i.e. Adding this property in the SCMI node in the proposed form).

Let me think and give others a chance to express their opinion.

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 4:36 PM, Sudeep Holla wrote:

Hello Sudeep,

>> This is not platform-specific issue. SCMI provider which fails to generate
>> interrupts can appear on any platform, using either transport, that is why I
>> made the property generic.
>>
> 
> Good point, but ideally this is property of the transport itself. For example,
> what does this "arm,poll-transport" can possibly mean for SMC/Optee transport ?

It actually is a property of the transport, except it applies to all 
transports (mailbox, smc, virtio). For Optee transport, this is 
implicitly true, since Optee transport always uses polling in any case, 
so the property has no effect.

> I understand this is a valid request, just not sure if this is the right way
> to solve( i.e. Adding this property in the SCMI node in the proposed form).
> 
> Let me think and give others a chance to express their opinion.

Sure, thank you !

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Thu, Oct 23, 2025 at 02:16:39PM +0100, Sudeep Holla wrote:
> On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
> > Document new property arm,poll-transport, which sets all SCMI operation into
> > poll mode. This is meant to work around uncooperative SCP implementations,
> > which do not generate completion interrupts. This applies primarily on mbox
> > based implementations, but does also cover SMC and VirtIO ones.
> > 
> > With this property set, such implementations which do not generate interrupts
> > can be interacted with, until they are fixed to generate interrupts properly.
> > 
> > Note that, because the original base protocol exchange also requires some
> > sort of completion mechanism, it is not possible to query SCMI itself for
> > this property and it must be described in DT. While this does look a bit
> > like policy, the SCMI provider is part of the hardware, hence DT.
> > 
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> > ---
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: Cristian Marussi <cristian.marussi@arm.com>
> > Cc: Florian Fainelli <florian.fainelli@broadcom.com>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: arm-scmi@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> >  Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index be817fd9cc34b..b53754a318ea1 100644
> > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > @@ -146,6 +146,13 @@ properties:
> >        this platform. If set, the value should be non-zero.
> >      minimum: 1
> >  
> > +  arm,poll-transport:
> > +    type: boolean
> > +    description:
> > +      An optional property which unconditionally forces polling in all transports.
> > +      This is mainly mean to work around uncooperative SCP, which does not generate
> > +      completion interrupts.
> > +
> 
> Could you please clarify which platform and transport this change pertains to?
> 
> Introducing a property that enforces unconditional polling across all
> platforms is not ideal - particularly if this is intended as a workaround
> for a platform- or firmware- specific issue. Such implementations often get
> replicated across platforms without addressing the root cause, leading to
> wider inconsistencies.
> 

Just to clarify what I mean by "enforces unconditional polling" is with the
added DT property only. I understand this is new property and it much be
present in DT to enforce polling, but it can be misused initially for testing
in absence of interrupt support and forgotten in DT. Hence my concern.

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 3:42 PM, Sudeep Holla wrote:

Hello Sudeep,

>>> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>>> index be817fd9cc34b..b53754a318ea1 100644
>>> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>>> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>>> @@ -146,6 +146,13 @@ properties:
>>>         this platform. If set, the value should be non-zero.
>>>       minimum: 1
>>>   
>>> +  arm,poll-transport:
>>> +    type: boolean
>>> +    description:
>>> +      An optional property which unconditionally forces polling in all transports.
>>> +      This is mainly mean to work around uncooperative SCP, which does not generate
>>> +      completion interrupts.
>>> +
>>
>> Could you please clarify which platform and transport this change pertains to?
>>
>> Introducing a property that enforces unconditional polling across all
>> platforms is not ideal - particularly if this is intended as a workaround
>> for a platform- or firmware- specific issue. Such implementations often get
>> replicated across platforms without addressing the root cause, leading to
>> wider inconsistencies.
>>
> 
> Just to clarify what I mean by "enforces unconditional polling" is with the
> added DT property only. I understand this is new property and it much be
> present in DT to enforce polling, but it can be misused initially for testing
> in absence of interrupt support and forgotten in DT. Hence my concern.

I would argue about the "mis" part of "misused" . It can be both "used" 
and "misused". I can add stronger warning into the description ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Cristian Marussi]

On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
> Document new property arm,poll-transport, which sets all SCMI operation into
> poll mode. This is meant to work around uncooperative SCP implementations,
> which do not generate completion interrupts. This applies primarily on mbox
> based implementations, but does also cover SMC and VirtIO ones.

Hi,

..indeed I was thinking a while ago about exposing the existing force-polling
switch but in my case it was purely a testing-scenario configuration, so a
no-no for the DT, things are different if you have to describe an HW that has
no completion IRQ also on the a2p channel...

...having said that, though, usually polling-mode is reserved to a few
selected commands in a few chosen scenarios (as you may have seen),
'carpet-polling' non-for-testing for all the commands on A2P seems a lot
inefficient and heavy...is it really a viable solution ? or these
systems use such a low rate of SCMI messages that polling after each and
every message is negligible ?

..just to understand the context...

> 
> With this property set, such implementations which do not generate interrupts
> can be interacted with, until they are fixed to generate interrupts properly.
> 
> Note that, because the original base protocol exchange also requires some
> sort of completion mechanism, it is not possible to query SCMI itself for
> this property and it must be described in DT. While this does look a bit
> like policy, the SCMI provider is part of the hardware, hence DT.
> 
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Thanks,
Cristian

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 3:45 PM, Cristian Marussi wrote:

Hello Cristian,

> On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
>> Document new property arm,poll-transport, which sets all SCMI operation into
>> poll mode. This is meant to work around uncooperative SCP implementations,
>> which do not generate completion interrupts. This applies primarily on mbox
>> based implementations, but does also cover SMC and VirtIO ones.
> 
> Hi,
> 
> ..indeed I was thinking a while ago about exposing the existing force-polling
> switch but in my case it was purely a testing-scenario configuration, so a
> no-no for the DT, things are different if you have to describe an HW that has
> no completion IRQ also on the a2p channel...

Correct, at least until the SCP on this hardware is updated.

> ...having said that, though, usually polling-mode is reserved to a few
> selected commands in a few chosen scenarios (as you may have seen),
> 'carpet-polling' non-for-testing for all the commands on A2P seems a lot
> inefficient and heavy...is it really a viable solution ? or these
> systems use such a low rate of SCMI messages that polling after each and
> every message is negligible ?
> 
> ..just to understand the context...

These systems are early in development and it is likely that the SCP 
will be updated to generate interrupts properly. Currently, this is not 
the case, hence the carpet-polling, until this is resolved.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 10/23/25 4:00 PM, Marek Vasut wrote:

Hello again,

>> On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
>>> Document new property arm,poll-transport, which sets all SCMI 
>>> operation into
>>> poll mode. This is meant to work around uncooperative SCP 
>>> implementations,
>>> which do not generate completion interrupts. This applies primarily 
>>> on mbox
>>> based implementations, but does also cover SMC and VirtIO ones.
>>
>> Hi,
>>
>> ..indeed I was thinking a while ago about exposing the existing force- 
>> polling
>> switch but in my case it was purely a testing-scenario configuration, 
>> so a
>> no-no for the DT, things are different if you have to describe an HW 
>> that has
>> no completion IRQ also on the a2p channel...
> 
> Correct, at least until the SCP on this hardware is updated.
> 
>> ...having said that, though, usually polling-mode is reserved to a few
>> selected commands in a few chosen scenarios (as you may have seen),
>> 'carpet-polling' non-for-testing for all the commands on A2P seems a lot
>> inefficient and heavy...is it really a viable solution ? or these
>> systems use such a low rate of SCMI messages that polling after each and
>> every message is negligible ?
>>
>> ..just to understand the context...
> 
> These systems are early in development and it is likely that the SCP 
> will be updated to generate interrupts properly. Currently, this is not 
> the case, hence the carpet-polling, until this is resolved.

While I was going through the SCMI spec, DEN0056F , page 209 , section 
"4.1 Shared memory based transport" , bullet • Completion interrupts, I 
found it explicitly states:

"
This transport supports polling or interrupt driven modes of 
communication. In interrupt mode, when the callee completes processing a 
message, it raises an interrupt to the caller. Hardware support for 
completion interrupts is optional.
"

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Cristian Marussi]

On Thu, Oct 30, 2025 at 01:52:42AM +0100, Marek Vasut wrote:
> On 10/23/25 4:00 PM, Marek Vasut wrote:
> 
> Hello again,
> 

Hi,

bit of a late reply...

> > > On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
> > > > Document new property arm,poll-transport, which sets all SCMI
> > > > operation into
> > > > poll mode. This is meant to work around uncooperative SCP
> > > > implementations,
> > > > which do not generate completion interrupts. This applies
> > > > primarily on mbox
> > > > based implementations, but does also cover SMC and VirtIO ones.
> > > 
> > > Hi,
> > > 
> > > ..indeed I was thinking a while ago about exposing the existing
> > > force- polling
> > > switch but in my case it was purely a testing-scenario
> > > configuration, so a
> > > no-no for the DT, things are different if you have to describe an HW
> > > that has
> > > no completion IRQ also on the a2p channel...
> > 
> > Correct, at least until the SCP on this hardware is updated.
> > 
> > > ...having said that, though, usually polling-mode is reserved to a few
> > > selected commands in a few chosen scenarios (as you may have seen),
> > > 'carpet-polling' non-for-testing for all the commands on A2P seems a lot
> > > inefficient and heavy...is it really a viable solution ? or these
> > > systems use such a low rate of SCMI messages that polling after each and
> > > every message is negligible ?
> > > 
> > > ..just to understand the context...
> > 
> > These systems are early in development and it is likely that the SCP
> > will be updated to generate interrupts properly. Currently, this is not
> > the case, hence the carpet-polling, until this is resolved.
> 
> While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
> Shared memory based transport" , bullet • Completion interrupts, I found it
> explicitly states:
> 
> "
> This transport supports polling or interrupt driven modes of communication.
> In interrupt mode, when the callee completes processing a message, it raises
> an interrupt to the caller. Hardware support for completion interrupts is
> optional.
> "

Oh, yes...I knew that...it is just that till now, no systems were really
ever developed that lacked the completion IRQ as a whole, it was, till now,
more of a case of having the capability NOT to use it selectively at runtime
and instead use polling when wanted (like for clock ops in ISR context)

I am not sure what is the reason why this only-polling scenario was never
supported in the HW description, this indeed pre-dates my work on SCMI....
...I would/will check with Sudeep, when he's back, what are the reasons for
this (if any)...

Thanks,
Cristian

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 11/13/25 12:03 PM, Cristian Marussi wrote:

Hello Cristian,

> bit of a late reply...

No worries, I am buried under email myself, take your time.

>>>> On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
>>>>> Document new property arm,poll-transport, which sets all SCMI
>>>>> operation into
>>>>> poll mode. This is meant to work around uncooperative SCP
>>>>> implementations,
>>>>> which do not generate completion interrupts. This applies
>>>>> primarily on mbox
>>>>> based implementations, but does also cover SMC and VirtIO ones.
>>>>
>>>> Hi,
>>>>
>>>> ..indeed I was thinking a while ago about exposing the existing
>>>> force- polling
>>>> switch but in my case it was purely a testing-scenario
>>>> configuration, so a
>>>> no-no for the DT, things are different if you have to describe an HW
>>>> that has
>>>> no completion IRQ also on the a2p channel...
>>>
>>> Correct, at least until the SCP on this hardware is updated.
>>>
>>>> ...having said that, though, usually polling-mode is reserved to a few
>>>> selected commands in a few chosen scenarios (as you may have seen),
>>>> 'carpet-polling' non-for-testing for all the commands on A2P seems a lot
>>>> inefficient and heavy...is it really a viable solution ? or these
>>>> systems use such a low rate of SCMI messages that polling after each and
>>>> every message is negligible ?
>>>>
>>>> ..just to understand the context...
>>>
>>> These systems are early in development and it is likely that the SCP
>>> will be updated to generate interrupts properly. Currently, this is not
>>> the case, hence the carpet-polling, until this is resolved.
>>
>> While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
>> Shared memory based transport" , bullet • Completion interrupts, I found it
>> explicitly states:
>>
>> "
>> This transport supports polling or interrupt driven modes of communication.
>> In interrupt mode, when the callee completes processing a message, it raises
>> an interrupt to the caller. Hardware support for completion interrupts is
>> optional.
>> "
> 
> Oh, yes...I knew that...it is just that till now, no systems were really
> ever developed that lacked the completion IRQ as a whole, it was, till now,
> more of a case of having the capability NOT to use it selectively at runtime
> and instead use polling when wanted (like for clock ops in ISR context)
> 
> I am not sure what is the reason why this only-polling scenario was never
> supported in the HW description, this indeed pre-dates my work on SCMI....
> ...I would/will check with Sudeep, when he's back, what are the reasons for
> this (if any)...

Thank you !

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Wolfram Sang]

Hi Cristian, Marek, all,

I am working with Marek on the same project.

> > While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
> > Shared memory based transport" , bullet • Completion interrupts, I found it
> > explicitly states:
> > 
> > "
> > This transport supports polling or interrupt driven modes of communication.
> > In interrupt mode, when the callee completes processing a message, it raises
> > an interrupt to the caller. Hardware support for completion interrupts is
> > optional.
> > "
> 
> Oh, yes...I knew that...it is just that till now, no systems were really
> ever developed that lacked the completion IRQ as a whole, it was, till now,
> more of a case of having the capability NOT to use it selectively at runtime
> and instead use polling when wanted (like for clock ops in ISR context)

So, I also read in the spec that completion irq is optional and wondered
why it was not possible to describe that in DT. And while we do strive
to get the SCP fixed alone for technical reasons (it is just better),
the spec doesn't actually require this, right? So, my suggestion for v2
is to reword the commit messages a little. More in the direction of
"support irqless implementations" rather than "support broken FW until
fixed". Or?

> I am not sure what is the reason why this only-polling scenario was never
> supported in the HW description, this indeed pre-dates my work on SCMI....
> ...I would/will check with Sudeep, when he's back, what are the reasons for
> this (if any)...

Cool, thank you. Looking forward to hear about it!

Happy hacking,

   Wolfram

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Thu, Nov 13, 2025 at 11:03:33AM +0000, Cristian Marussi wrote:
> On Thu, Oct 30, 2025 at 01:52:42AM +0100, Marek Vasut wrote:
> > On 10/23/25 4:00 PM, Marek Vasut wrote:
> > 
> > Hello again,
> > 
> 
> Hi,
> 
> bit of a late reply...
> 
> > > > On Thu, Oct 23, 2025 at 02:35:57PM +0200, Marek Vasut wrote:
> > > > > Document new property arm,poll-transport, which sets all SCMI
> > > > > operation into
> > > > > poll mode. This is meant to work around uncooperative SCP
> > > > > implementations,
> > > > > which do not generate completion interrupts. This applies
> > > > > primarily on mbox
> > > > > based implementations, but does also cover SMC and VirtIO ones.
> > > > 
> > > > Hi,
> > > > 
> > > > ..indeed I was thinking a while ago about exposing the existing
> > > > force- polling
> > > > switch but in my case it was purely a testing-scenario
> > > > configuration, so a
> > > > no-no for the DT, things are different if you have to describe an HW
> > > > that has
> > > > no completion IRQ also on the a2p channel...
> > > 
> > > Correct, at least until the SCP on this hardware is updated.
> > > 
> > > > ...having said that, though, usually polling-mode is reserved to a few
> > > > selected commands in a few chosen scenarios (as you may have seen),
> > > > 'carpet-polling' non-for-testing for all the commands on A2P seems a lot
> > > > inefficient and heavy...is it really a viable solution ? or these
> > > > systems use such a low rate of SCMI messages that polling after each and
> > > > every message is negligible ?
> > > > 
> > > > ..just to understand the context...
> > > 
> > > These systems are early in development and it is likely that the SCP
> > > will be updated to generate interrupts properly. Currently, this is not
> > > the case, hence the carpet-polling, until this is resolved.
> > 
> > While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
> > Shared memory based transport" , bullet • Completion interrupts, I found it
> > explicitly states:
> > 
> > "
> > This transport supports polling or interrupt driven modes of communication.
> > In interrupt mode, when the callee completes processing a message, it raises
> > an interrupt to the caller. Hardware support for completion interrupts is
> > optional.
> > "
> 
> Oh, yes...I knew that...it is just that till now, no systems were really
> ever developed that lacked the completion IRQ as a whole, it was, till now,
> more of a case of having the capability NOT to use it selectively at runtime
> and instead use polling when wanted (like for clock ops in ISR context)
> 

Indeed.

> I am not sure what is the reason why this only-polling scenario was never
> supported in the HW description, this indeed pre-dates my work on SCMI....
> ...I would/will check with Sudeep, when he's back, what are the reasons for
> this (if any)...
> 

As you mentioned earlier, no platform has required this before. I’m fine with
adding it, but we need to be more explicit about what it implies for SCMI. The
transport may be shared with other system components, and enforcing polling
for SCMI while the same transport generates interrupts for another user could
lead to issues.

Clearly defining these constraints would be helpful. It may also be useful to
note that this is primarily intended for mailbox transports, if that’s
accurate. Alternatively, we could keep the DT binding definition broader but
emit warnings when a transport other than mailbox is used. That approach might
make it easier to move forward.

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 12/2/25 3:52 PM, Sudeep Holla wrote:

Hello Sudeep,

>>> While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
>>> Shared memory based transport" , bullet • Completion interrupts, I found it
>>> explicitly states:
>>>
>>> "
>>> This transport supports polling or interrupt driven modes of communication.
>>> In interrupt mode, when the callee completes processing a message, it raises
>>> an interrupt to the caller. Hardware support for completion interrupts is
>>> optional.
>>> "
>>
>> Oh, yes...I knew that...it is just that till now, no systems were really
>> ever developed that lacked the completion IRQ as a whole, it was, till now,
>> more of a case of having the capability NOT to use it selectively at runtime
>> and instead use polling when wanted (like for clock ops in ISR context)
>>
> 
> Indeed.
> 
>> I am not sure what is the reason why this only-polling scenario was never
>> supported in the HW description, this indeed pre-dates my work on SCMI....
>> ...I would/will check with Sudeep, when he's back, what are the reasons for
>> this (if any)...
>>
> 
> As you mentioned earlier, no platform has required this before. I’m fine with
> adding it, but we need to be more explicit about what it implies for SCMI. The
> transport may be shared with other system components, and enforcing polling
> for SCMI while the same transport generates interrupts for another user could
> lead to issues.

How do you imagine this -- a transport shared with other components, one 
which does generate IRQs and one which does not -- would look like ? Can 
you think of an example ?

> Clearly defining these constraints would be helpful. It may also be useful to
> note that this is primarily intended for mailbox transports, if that’s
> accurate. Alternatively, we could keep the DT binding definition broader but
> emit warnings when a transport other than mailbox is used. That approach might
> make it easier to move forward.

DEN0056F refers to this polling mode in Shared memory based transports, 
that can be other than mailbox transports, it includes e.g. SMC or OPTEE 
transports.

I don't think a warning is justified, if the behavior follows the 
specification. But I do agree the behavior is ... suboptimal.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Tue, Dec 02, 2025 at 05:36:53PM +0100, Marek Vasut wrote:
> On 12/2/25 3:52 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > > While I was going through the SCMI spec, DEN0056F , page 209 , section "4.1
> > > > Shared memory based transport" , bullet • Completion interrupts, I found it
> > > > explicitly states:
> > > > 
> > > > "
> > > > This transport supports polling or interrupt driven modes of communication.
> > > > In interrupt mode, when the callee completes processing a message, it raises
> > > > an interrupt to the caller. Hardware support for completion interrupts is
> > > > optional.
> > > > "
> > > 
> > > Oh, yes...I knew that...it is just that till now, no systems were really
> > > ever developed that lacked the completion IRQ as a whole, it was, till now,
> > > more of a case of having the capability NOT to use it selectively at runtime
> > > and instead use polling when wanted (like for clock ops in ISR context)
> > > 
> > 
> > Indeed.
> > 
> > > I am not sure what is the reason why this only-polling scenario was never
> > > supported in the HW description, this indeed pre-dates my work on SCMI....
> > > ...I would/will check with Sudeep, when he's back, what are the reasons for
> > > this (if any)...
> > > 
> > 
> > As you mentioned earlier, no platform has required this before. I’m fine with
> > adding it, but we need to be more explicit about what it implies for SCMI. The
> > transport may be shared with other system components, and enforcing polling
> > for SCMI while the same transport generates interrupts for another user could
> > lead to issues.
> 
> How do you imagine this -- a transport shared with other components, one
> which does generate IRQs and one which does not -- would look like ? Can you
> think of an example ?
> 

Consider a system where a mailbox controller is present and one channel is
used for SCMI communication, while another channel is used for an unrelated
purpose. If both channels share the same interrupt line, and the other use
case enables interrupt mode on its channel, what would be the impact on the
SCMI-specific channel?

I am aware of systems that implement such sharing, which is why I prefer to be
explicit that this type of design is challenging to support within this
binding. The intent is to support only minimal, constrained cases - essentially
systems that are already somewhat broken. I do not see value in broadening the
binding to cover every conceivable scenario.

> > Clearly defining these constraints would be helpful. It may also be useful to
> > note that this is primarily intended for mailbox transports, if that’s
> > accurate. Alternatively, we could keep the DT binding definition broader but
> > emit warnings when a transport other than mailbox is used. That approach might
> > make it easier to move forward.
> 
> DEN0056F refers to this polling mode in Shared memory based transports, that
> can be other than mailbox transports, it includes e.g. SMC or OPTEE
> transports.
> 

However, polling does not make sense in the context of SMC. Once control
returns from an SMC call, the command has completed. What form of polling in
an SMC workflow do you have in mind? I believe the same applies to OP-TEE.
While OP-TEE now provides a notification mechanism that could, in theory,
allow synchronous commands to be treated in a quasi-asynchronous manner, I
strongly doubt that the current SCMI-over-OP-TEE implementation behaves this
way, given that it ultimately reaches the secure side via an SMC call.

> I don't think a warning is justified, if the behavior follows the
> specification. But I do agree the behavior is ... suboptimal.
> 

The specification does not address SMC or OP-TEE transports, placing them
outside its scope and likewise these DT bindings. Consequently, what we
decide here in this discussion effectively defines the expected behavior in
this context, in my view. So I would like to start with minimal possible
coverage, why do you think that is not a good idea here ?

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 12/2/25 7:55 PM, Sudeep Holla wrote:

Hello Sudeep,

>> How do you imagine this -- a transport shared with other components, one
>> which does generate IRQs and one which does not -- would look like ? Can you
>> think of an example ?
>>
> 
> Consider a system where a mailbox controller is present and one channel is
> used for SCMI communication, while another channel is used for an unrelated
> purpose. If both channels share the same interrupt line, and the other use
> case enables interrupt mode on its channel, what would be the impact on the
> SCMI-specific channel?

None, SCMI kernel driver and SCMI server side would still do polling on 
their respective SHMEM areas, while whatever kernel driver needs to 
receive the interrupt notifications would subscribe to them using 
request_irq(), right ?

> I am aware of systems that implement such sharing, which is why I prefer to be
> explicit that this type of design is challenging to support within this
> binding. The intent is to support only minimal, constrained cases - essentially
> systems that are already somewhat broken. I do not see value in broadening the
> binding to cover every conceivable scenario.
> 
>>> Clearly defining these constraints would be helpful. It may also be useful to
>>> note that this is primarily intended for mailbox transports, if that’s
>>> accurate. Alternatively, we could keep the DT binding definition broader but
>>> emit warnings when a transport other than mailbox is used. That approach might
>>> make it easier to move forward.
>>
>> DEN0056F refers to this polling mode in Shared memory based transports, that
>> can be other than mailbox transports, it includes e.g. SMC or OPTEE
>> transports.
>>
> 
> However, polling does not make sense in the context of SMC. Once control
> returns from an SMC call, the command has completed. What form of polling in
> an SMC workflow do you have in mind?

I think the polling happens on the SHMEM and the SMC transport is 
capable of that too, see :

drivers/firmware/arm_scmi/transports/smc.c

175         /*
176          * If there is an interrupt named "a2p", then the service and
177          * completion of a message is signaled by an interrupt 
rather than by
178          * the return of the SMC call.
179          */
180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");

> I believe the same applies to OP-TEE.
> While OP-TEE now provides a notification mechanism that could, in theory,
> allow synchronous commands to be treated in a quasi-asynchronous manner, I
> strongly doubt that the current SCMI-over-OP-TEE implementation behaves this
> way, given that it ultimately reaches the secure side via an SMC call.
> 
>> I don't think a warning is justified, if the behavior follows the
>> specification. But I do agree the behavior is ... suboptimal.
>>
> 
> The specification does not address SMC or OP-TEE transports, placing them
> outside its scope and likewise these DT bindings.

I believe the shmem transport includes the SMC and OPTEE ones, right ?

> Consequently, what we
> decide here in this discussion effectively defines the expected behavior in
> this context, in my view. So I would like to start with minimal possible
> coverage, why do you think that is not a good idea here ?

I would argue the current implementation covers pretty much every 
transport which could ever need to do polling on shmem, so the 
implementation is generic and inline with the specification. Also, the 
current implementation is some 20 lines, so I think it is minimalistic?

What would you propose we do here ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Tue, Dec 02, 2025 at 08:25:11PM +0100, Marek Vasut wrote:
> On 12/2/25 7:55 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > How do you imagine this -- a transport shared with other components, one
> > > which does generate IRQs and one which does not -- would look like ? Can you
> > > think of an example ?
> > > 
> > 
> > Consider a system where a mailbox controller is present and one channel is
> > used for SCMI communication, while another channel is used for an unrelated
> > purpose. If both channels share the same interrupt line, and the other use
> > case enables interrupt mode on its channel, what would be the impact on the
> > SCMI-specific channel?
> 
> None, SCMI kernel driver and SCMI server side would still do polling on
> their respective SHMEM areas, while whatever kernel driver needs to receive
> the interrupt notifications would subscribe to them using request_irq(),
> right ?
> 

Fair enough. I was thinking if the controller manages to not call
mbox_chan_received_data() in that case. Also IIUC, the irq request happens
as part of channel startup and there are no explicit APIs for the mbox client
driver to control that. SCMI is mbox client in this case.

> > I am aware of systems that implement such sharing, which is why I prefer to be
> > explicit that this type of design is challenging to support within this
> > binding. The intent is to support only minimal, constrained cases - essentially
> > systems that are already somewhat broken. I do not see value in broadening the
> > binding to cover every conceivable scenario.
> > 
> > > > Clearly defining these constraints would be helpful. It may also be useful to
> > > > note that this is primarily intended for mailbox transports, if that’s
> > > > accurate. Alternatively, we could keep the DT binding definition broader but
> > > > emit warnings when a transport other than mailbox is used. That approach might
> > > > make it easier to move forward.
> > > 
> > > DEN0056F refers to this polling mode in Shared memory based transports, that
> > > can be other than mailbox transports, it includes e.g. SMC or OPTEE
> > > transports.
> > > 
> > 
> > However, polling does not make sense in the context of SMC. Once control
> > returns from an SMC call, the command has completed. What form of polling in
> > an SMC workflow do you have in mind?
> 
> I think the polling happens on the SHMEM and the SMC transport is capable of
> that too, see :
> 
> drivers/firmware/arm_scmi/transports/smc.c
> 
> 175         /*
> 176          * If there is an interrupt named "a2p", then the service and
> 177          * completion of a message is signaled by an interrupt rather
> than by
> 178          * the return of the SMC call.
> 179          */
> 180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
> 

Ah this one, is actually implemented to avoid sort of implicit polling
mode we get with any SMC/HVC. I don't know how the platform deals with it
but SMC/HVC is synchronous and doesn't need this polling. The irq introduced
here is again a sort of workaround to get some sort of async/non-polling
mode with SMC/HVC. So, to repeat polling mode make absolutely no sense
whatsoever for SMC/OPTEE(based on pure SMC) transports.

> > I believe the same applies to OP-TEE.
> > While OP-TEE now provides a notification mechanism that could, in theory,
> > allow synchronous commands to be treated in a quasi-asynchronous manner, I
> > strongly doubt that the current SCMI-over-OP-TEE implementation behaves this
> > way, given that it ultimately reaches the secure side via an SMC call.
> > 
> > > I don't think a warning is justified, if the behavior follows the
> > > specification. But I do agree the behavior is ... suboptimal.
> > > 
> > 
> > The specification does not address SMC or OP-TEE transports, placing them
> > outside its scope and likewise these DT bindings.
> 
> I believe the shmem transport includes the SMC and OPTEE ones, right ?
>

Yes, but the expectation when the SMC completes is to have the shmem to be
owned by the OS(except that irq workaround case). Again the OPTEE/SMC is
completely out of spec, but I agree the SHMEM behaviour must conform to the
specification.

> > Consequently, what we
> > decide here in this discussion effectively defines the expected behavior in
> > this context, in my view. So I would like to start with minimal possible
> > coverage, why do you think that is not a good idea here ?
> 
> I would argue the current implementation covers pretty much every transport
> which could ever need to do polling on shmem, so the implementation is
> generic and inline with the specification. Also, the current implementation
> is some 20 lines, so I think it is minimalistic?
> 
> What would you propose we do here ?
> 

Yes it can be minimalistic but not restrictive. As I already clearly mentioned
I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
just mailbox to start with and extend to other transports if and when needed.
It would be good to impose that restriction in the binding as well but that
is not a must IMO. I am fine if the bindings for whatever reasons(though I
don't see the need) to apply for any transport.

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 12/3/25 12:41 PM, Sudeep Holla wrote:

Hello Sudeep,

>>> Consider a system where a mailbox controller is present and one channel is
>>> used for SCMI communication, while another channel is used for an unrelated
>>> purpose. If both channels share the same interrupt line, and the other use
>>> case enables interrupt mode on its channel, what would be the impact on the
>>> SCMI-specific channel?
>>
>> None, SCMI kernel driver and SCMI server side would still do polling on
>> their respective SHMEM areas, while whatever kernel driver needs to receive
>> the interrupt notifications would subscribe to them using request_irq(),
>> right ?
>>
> 
> Fair enough. I was thinking if the controller manages to not call
> mbox_chan_received_data() in that case.

Wouldn't such a setup use separate mailbox channels , therefore even if 
mailbox driver calls mbox_chan_received_data(), it would be called for a 
specific mailbox channel , and it won't interfere with the SCMI mailbox 
channel.

> Also IIUC, the irq request happens
> as part of channel startup and there are no explicit APIs for the mbox client
> driver to control that. SCMI is mbox client in this case.

Sure, but the mailbox driver has to make sure it is correctly demuxing 
the IRQs it handles and correctly sends received_data notifications to 
the right channel(s) .

>>> I am aware of systems that implement such sharing, which is why I prefer to be
>>> explicit that this type of design is challenging to support within this
>>> binding. The intent is to support only minimal, constrained cases - essentially
>>> systems that are already somewhat broken. I do not see value in broadening the
>>> binding to cover every conceivable scenario.
>>>
>>>>> Clearly defining these constraints would be helpful. It may also be useful to
>>>>> note that this is primarily intended for mailbox transports, if that’s
>>>>> accurate. Alternatively, we could keep the DT binding definition broader but
>>>>> emit warnings when a transport other than mailbox is used. That approach might
>>>>> make it easier to move forward.
>>>>
>>>> DEN0056F refers to this polling mode in Shared memory based transports, that
>>>> can be other than mailbox transports, it includes e.g. SMC or OPTEE
>>>> transports.
>>>>
>>>
>>> However, polling does not make sense in the context of SMC. Once control
>>> returns from an SMC call, the command has completed. What form of polling in
>>> an SMC workflow do you have in mind?
>>
>> I think the polling happens on the SHMEM and the SMC transport is capable of
>> that too, see :
>>
>> drivers/firmware/arm_scmi/transports/smc.c
>>
>> 175         /*
>> 176          * If there is an interrupt named "a2p", then the service and
>> 177          * completion of a message is signaled by an interrupt rather
>> than by
>> 178          * the return of the SMC call.
>> 179          */
>> 180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
>>
> 
> Ah this one, is actually implemented to avoid sort of implicit polling
> mode we get with any SMC/HVC. I don't know how the platform deals with it
> but SMC/HVC is synchronous and doesn't need this polling. The irq introduced
> here is again a sort of workaround to get some sort of async/non-polling
> mode with SMC/HVC. So, to repeat polling mode make absolutely no sense
> whatsoever for SMC/OPTEE(based on pure SMC) transports.

I can drop the SMC part from this patch if you think that's helpful ?

>>> I believe the same applies to OP-TEE.
>>> While OP-TEE now provides a notification mechanism that could, in theory,
>>> allow synchronous commands to be treated in a quasi-asynchronous manner, I
>>> strongly doubt that the current SCMI-over-OP-TEE implementation behaves this
>>> way, given that it ultimately reaches the secure side via an SMC call.
>>>
>>>> I don't think a warning is justified, if the behavior follows the
>>>> specification. But I do agree the behavior is ... suboptimal.
>>>>
>>>
>>> The specification does not address SMC or OP-TEE transports, placing them
>>> outside its scope and likewise these DT bindings.
>>
>> I believe the shmem transport includes the SMC and OPTEE ones, right ?
>>
> 
> Yes, but the expectation when the SMC completes is to have the shmem to be
> owned by the OS(except that irq workaround case). Again the OPTEE/SMC is
> completely out of spec, but I agree the SHMEM behaviour must conform to the
> specification.

OK

>>> Consequently, what we
>>> decide here in this discussion effectively defines the expected behavior in
>>> this context, in my view. So I would like to start with minimal possible
>>> coverage, why do you think that is not a good idea here ?
>>
>> I would argue the current implementation covers pretty much every transport
>> which could ever need to do polling on shmem, so the implementation is
>> generic and inline with the specification. Also, the current implementation
>> is some 20 lines, so I think it is minimalistic?
>>
>> What would you propose we do here ?
>>
> 
> Yes it can be minimalistic but not restrictive. As I already clearly mentioned
> I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
> just mailbox to start with and extend to other transports if and when needed.
> It would be good to impose that restriction in the binding as well but that
> is not a must IMO. I am fine if the bindings for whatever reasons(though I
> don't see the need) to apply for any transport.
So I should simply drop the smc.c changes , keep the rest, and send V2 ?

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Wed, Dec 03, 2025 at 11:53:41PM +0100, Marek Vasut wrote:
> On 12/3/25 12:41 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > > Consider a system where a mailbox controller is present and one channel is
> > > > used for SCMI communication, while another channel is used for an unrelated
> > > > purpose. If both channels share the same interrupt line, and the other use
> > > > case enables interrupt mode on its channel, what would be the impact on the
> > > > SCMI-specific channel?
> > > 
> > > None, SCMI kernel driver and SCMI server side would still do polling on
> > > their respective SHMEM areas, while whatever kernel driver needs to receive
> > > the interrupt notifications would subscribe to them using request_irq(),
> > > right ?
> > > 
> > 
> > Fair enough. I was thinking if the controller manages to not call
> > mbox_chan_received_data() in that case.
> 
> Wouldn't such a setup use separate mailbox channels, therefore even if
> mailbox driver calls mbox_chan_received_data(), it would be called for a
> specific mailbox channel , and it won't interfere with the SCMI mailbox
> channel.
> 

Ideally yes. Because PCC uses shared interrupts and provides no mechanism to
identify the channel that raised the interrupt, we must run the handler for
every registered channel. This behaviour is specific to PCC; other controllers
that support interrupt source detection may not need to do this. But SCMI
must work with any mailbox or other transports.

> > Also IIUC, the irq request happens
> > as part of channel startup and there are no explicit APIs for the mbox client
> > driver to control that. SCMI is mbox client in this case.
> 
> Sure, but the mailbox driver has to make sure it is correctly demuxing the
> IRQs it handles and correctly sends received_data notifications to the right
> channel(s) .
> 

Agreed, but the concern is that if SCMI is forced to use polling when the
channel is opened, and IRQs are enabled by default with no way for SCMI to
disable them in polling mode, we could run into issues. I realise it’s a very
specific corner case, but every time I’ve assumed such scenarios wouldn’t
occur, we eventually ended up encountering them. So sorry if I am very
pedantic, but I prefer to start smaller and restrictive and expand if and
when necessary or required only.

> > > > I am aware of systems that implement such sharing, which is why I prefer to be
> > > > explicit that this type of design is challenging to support within this
> > > > binding. The intent is to support only minimal, constrained cases - essentially
> > > > systems that are already somewhat broken. I do not see value in broadening the
> > > > binding to cover every conceivable scenario.
> > > > 
> > > > > > Clearly defining these constraints would be helpful. It may also be useful to
> > > > > > note that this is primarily intended for mailbox transports, if that’s
> > > > > > accurate. Alternatively, we could keep the DT binding definition broader but
> > > > > > emit warnings when a transport other than mailbox is used. That approach might
> > > > > > make it easier to move forward.
> > > > > 
> > > > > DEN0056F refers to this polling mode in Shared memory based transports, that
> > > > > can be other than mailbox transports, it includes e.g. SMC or OPTEE
> > > > > transports.
> > > > > 
> > > > 
> > > > However, polling does not make sense in the context of SMC. Once control
> > > > returns from an SMC call, the command has completed. What form of polling in
> > > > an SMC workflow do you have in mind?
> > > 
> > > I think the polling happens on the SHMEM and the SMC transport is capable of
> > > that too, see :
> > > 
> > > drivers/firmware/arm_scmi/transports/smc.c
> > > 
> > > 175         /*
> > > 176          * If there is an interrupt named "a2p", then the service and
> > > 177          * completion of a message is signaled by an interrupt rather
> > > than by
> > > 178          * the return of the SMC call.
> > > 179          */
> > > 180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
> > > 
> > 
> > Ah this one, is actually implemented to avoid sort of implicit polling
> > mode we get with any SMC/HVC. I don't know how the platform deals with it
> > but SMC/HVC is synchronous and doesn't need this polling. The irq introduced
> > here is again a sort of workaround to get some sort of async/non-polling
> > mode with SMC/HVC. So, to repeat polling mode make absolutely no sense
> > whatsoever for SMC/OPTEE(based on pure SMC) transports.
> 
> I can drop the SMC part from this patch if you think that's helpful ?
> 

Yes, that’s essential, because polling in an SMC context is meaningless in my
opinion.

> > > > I believe the same applies to OP-TEE.
> > > > While OP-TEE now provides a notification mechanism that could, in theory,
> > > > allow synchronous commands to be treated in a quasi-asynchronous manner, I
> > > > strongly doubt that the current SCMI-over-OP-TEE implementation behaves this
> > > > way, given that it ultimately reaches the secure side via an SMC call.
> > > > 
> > > > > I don't think a warning is justified, if the behavior follows the
> > > > > specification. But I do agree the behavior is ... suboptimal.
> > > > > 
> > > > 
> > > > The specification does not address SMC or OP-TEE transports, placing them
> > > > outside its scope and likewise these DT bindings.
> > > 
> > > I believe the shmem transport includes the SMC and OPTEE ones, right ?
> > > 
> > 
> > Yes, but the expectation when the SMC completes is to have the shmem to be
> > owned by the OS(except that irq workaround case). Again the OPTEE/SMC is
> > completely out of spec, but I agree the SHMEM behaviour must conform to the
> > specification.
> 
> OK
> 
> > > > Consequently, what we
> > > > decide here in this discussion effectively defines the expected behavior in
> > > > this context, in my view. So I would like to start with minimal possible
> > > > coverage, why do you think that is not a good idea here ?
> > > 
> > > I would argue the current implementation covers pretty much every transport
> > > which could ever need to do polling on shmem, so the implementation is
> > > generic and inline with the specification. Also, the current implementation
> > > is some 20 lines, so I think it is minimalistic?
> > > 
> > > What would you propose we do here ?
> > > 
> > 
> > Yes it can be minimalistic but not restrictive. As I already clearly mentioned
> > I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
> > just mailbox to start with and extend to other transports if and when needed.
> > It would be good to impose that restriction in the binding as well but that
> > is not a must IMO. I am fine if the bindings for whatever reasons(though I
> > don't see the need) to apply for any transport.
> So I should simply drop the smc.c changes , keep the rest, and send V2 ?

Not just that. Unless DT maintainers oppose, I just want to keep this
new property valid only for mailbox transport(i.e. "arm,scmi" compatible
not otherwise) so that we can catch any other use in binding checks and
interested parties must discuss on the list and expand that if they require.

Also we can explore if we can parse and scan this in mailbox transport for
now.

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 12/4/25 1:33 PM, Sudeep Holla wrote:

Hello Sudeep,

>> Wouldn't such a setup use separate mailbox channels, therefore even if
>> mailbox driver calls mbox_chan_received_data(), it would be called for a
>> specific mailbox channel , and it won't interfere with the SCMI mailbox
>> channel.
>>
> 
> Ideally yes. Because PCC uses shared interrupts and provides no mechanism to
> identify the channel that raised the interrupt, we must run the handler for
> every registered channel. This behaviour is specific to PCC; other controllers
> that support interrupt source detection may not need to do this. But SCMI
> must work with any mailbox or other transports.

It seems the pcc_mbox_irq() operates per-channel, so it seems even the 
PCC can demux channels for each IRQ and does trigger 
mbox_chan_received_data() for correct channel ?

What exactly happens on the PCC mailbox driver with this polling mode 
enabled ?

>>> Also IIUC, the irq request happens
>>> as part of channel startup and there are no explicit APIs for the mbox client
>>> driver to control that. SCMI is mbox client in this case.
>>
>> Sure, but the mailbox driver has to make sure it is correctly demuxing the
>> IRQs it handles and correctly sends received_data notifications to the right
>> channel(s) .
>>
> 
> Agreed, but the concern is that if SCMI is forced to use polling when the
> channel is opened, and IRQs are enabled by default with no way for SCMI to
> disable them in polling mode, we could run into issues.

This constellation seems odd -- if the channel can do IRQs, then this 
property should not be present in DT.

> I realise it’s a very
> specific corner case, but every time I’ve assumed such scenarios wouldn’t
> occur, we eventually ended up encountering them. So sorry if I am very
> pedantic, but I prefer to start smaller and restrictive and expand if and
> when necessary or required only.

I don't think this case, where mailbox channel does IRQs and polling is 
enabled, can/should even be considered valid. Either the channel does 
not do IRQs and then it should do polling, or it does IRQs and then it 
should use IRQs, but not both.

>>>>> I am aware of systems that implement such sharing, which is why I prefer to be
>>>>> explicit that this type of design is challenging to support within this
>>>>> binding. The intent is to support only minimal, constrained cases - essentially
>>>>> systems that are already somewhat broken. I do not see value in broadening the
>>>>> binding to cover every conceivable scenario.
>>>>>
>>>>>>> Clearly defining these constraints would be helpful. It may also be useful to
>>>>>>> note that this is primarily intended for mailbox transports, if that’s
>>>>>>> accurate. Alternatively, we could keep the DT binding definition broader but
>>>>>>> emit warnings when a transport other than mailbox is used. That approach might
>>>>>>> make it easier to move forward.
>>>>>>
>>>>>> DEN0056F refers to this polling mode in Shared memory based transports, that
>>>>>> can be other than mailbox transports, it includes e.g. SMC or OPTEE
>>>>>> transports.
>>>>>>
>>>>>
>>>>> However, polling does not make sense in the context of SMC. Once control
>>>>> returns from an SMC call, the command has completed. What form of polling in
>>>>> an SMC workflow do you have in mind?
>>>>
>>>> I think the polling happens on the SHMEM and the SMC transport is capable of
>>>> that too, see :
>>>>
>>>> drivers/firmware/arm_scmi/transports/smc.c
>>>>
>>>> 175         /*
>>>> 176          * If there is an interrupt named "a2p", then the service and
>>>> 177          * completion of a message is signaled by an interrupt rather
>>>> than by
>>>> 178          * the return of the SMC call.
>>>> 179          */
>>>> 180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
>>>>
>>>
>>> Ah this one, is actually implemented to avoid sort of implicit polling
>>> mode we get with any SMC/HVC. I don't know how the platform deals with it
>>> but SMC/HVC is synchronous and doesn't need this polling. The irq introduced
>>> here is again a sort of workaround to get some sort of async/non-polling
>>> mode with SMC/HVC. So, to repeat polling mode make absolutely no sense
>>> whatsoever for SMC/OPTEE(based on pure SMC) transports.
>>
>> I can drop the SMC part from this patch if you think that's helpful ?
>>
> 
> Yes, that’s essential, because polling in an SMC context is meaningless in my
> opinion.

Maybe the "a2p" IRQ is also used for notifications from longer running 
operations ?

[...]

>>> Yes it can be minimalistic but not restrictive. As I already clearly mentioned
>>> I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
>>> just mailbox to start with and extend to other transports if and when needed.
>>> It would be good to impose that restriction in the binding as well but that
>>> is not a must IMO. I am fine if the bindings for whatever reasons(though I
>>> don't see the need) to apply for any transport.
>> So I should simply drop the smc.c changes , keep the rest, and send V2 ?
> 
> Not just that. Unless DT maintainers oppose, I just want to keep this
> new property valid only for mailbox transport(i.e. "arm,scmi" compatible
> not otherwise) so that we can catch any other use in binding checks and
> interested parties must discuss on the list and expand that if they require.
> 
> Also we can explore if we can parse and scan this in mailbox transport for
> now.
I feel that this only adds more implementation complexity and makes the 
solution less generic, while it does win us very little in the end ? The 
generic solution implementation is actually easier to implement.

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Thu, Dec 04, 2025 at 07:59:20PM +0100, Marek Vasut wrote:
> On 12/4/25 1:33 PM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > Wouldn't such a setup use separate mailbox channels, therefore even if
> > > mailbox driver calls mbox_chan_received_data(), it would be called for a
> > > specific mailbox channel , and it won't interfere with the SCMI mailbox
> > > channel.
> > > 
> > 
> > Ideally yes. Because PCC uses shared interrupts and provides no mechanism to
> > identify the channel that raised the interrupt, we must run the handler for
> > every registered channel. This behaviour is specific to PCC; other controllers
> > that support interrupt source detection may not need to do this. But SCMI
> > must work with any mailbox or other transports.
> 
> It seems the pcc_mbox_irq() operates per-channel, so it seems even the PCC
> can demux channels for each IRQ and does trigger mbox_chan_received_data()
> for correct channel ?
> 
> What exactly happens on the PCC mailbox driver with this polling mode
> enabled ?
> 
> > > > Also IIUC, the irq request happens
> > > > as part of channel startup and there are no explicit APIs for the mbox client
> > > > driver to control that. SCMI is mbox client in this case.
> > > 
> > > Sure, but the mailbox driver has to make sure it is correctly demuxing the
> > > IRQs it handles and correctly sends received_data notifications to the right
> > > channel(s) .
> > > 
> > 
> > Agreed, but the concern is that if SCMI is forced to use polling when the
> > channel is opened, and IRQs are enabled by default with no way for SCMI to
> > disable them in polling mode, we could run into issues.
> 
> This constellation seems odd -- if the channel can do IRQs, then this
> property should not be present in DT.
> 

Yes, but there is no way to validate or check this and that is the root
cause for all my worries.

> > I realise it’s a very
> > specific corner case, but every time I’ve assumed such scenarios wouldn’t
> > occur, we eventually ended up encountering them. So sorry if I am very
> > pedantic, but I prefer to start smaller and restrictive and expand if and
> > when necessary or required only.
> 
> I don't think this case, where mailbox channel does IRQs and polling is
> enabled, can/should even be considered valid. Either the channel does not do
> IRQs and then it should do polling, or it does IRQs and then it should use
> IRQs, but not both.
> 

Yes ideally, but having loose ends like this binding which allows someone
to add it to their DT complicates though it is invalid. We have no way to
detect and I don't want to work around such configs in the future.

> > > > > > I am aware of systems that implement such sharing, which is why I prefer to be
> > > > > > explicit that this type of design is challenging to support within this
> > > > > > binding. The intent is to support only minimal, constrained cases - essentially
> > > > > > systems that are already somewhat broken. I do not see value in broadening the
> > > > > > binding to cover every conceivable scenario.
> > > > > > 
> > > > > > > > Clearly defining these constraints would be helpful. It may also be useful to
> > > > > > > > note that this is primarily intended for mailbox transports, if that’s
> > > > > > > > accurate. Alternatively, we could keep the DT binding definition broader but
> > > > > > > > emit warnings when a transport other than mailbox is used. That approach might
> > > > > > > > make it easier to move forward.
> > > > > > > 
> > > > > > > DEN0056F refers to this polling mode in Shared memory based transports, that
> > > > > > > can be other than mailbox transports, it includes e.g. SMC or OPTEE
> > > > > > > transports.
> > > > > > > 
> > > > > > 
> > > > > > However, polling does not make sense in the context of SMC. Once control
> > > > > > returns from an SMC call, the command has completed. What form of polling in
> > > > > > an SMC workflow do you have in mind?
> > > > > 
> > > > > I think the polling happens on the SHMEM and the SMC transport is capable of
> > > > > that too, see :
> > > > > 
> > > > > drivers/firmware/arm_scmi/transports/smc.c
> > > > > 
> > > > > 175         /*
> > > > > 176          * If there is an interrupt named "a2p", then the service and
> > > > > 177          * completion of a message is signaled by an interrupt rather
> > > > > than by
> > > > > 178          * the return of the SMC call.
> > > > > 179          */
> > > > > 180         scmi_info->irq = of_irq_get_byname(cdev->of_node, "a2p");
> > > > > 
> > > > 
> > > > Ah this one, is actually implemented to avoid sort of implicit polling
> > > > mode we get with any SMC/HVC. I don't know how the platform deals with it
> > > > but SMC/HVC is synchronous and doesn't need this polling. The irq introduced
> > > > here is again a sort of workaround to get some sort of async/non-polling
> > > > mode with SMC/HVC. So, to repeat polling mode make absolutely no sense
> > > > whatsoever for SMC/OPTEE(based on pure SMC) transports.
> > > 
> > > I can drop the SMC part from this patch if you think that's helpful ?
> > > 
> > 
> > Yes, that’s essential, because polling in an SMC context is meaningless in my
> > opinion.
> 
> Maybe the "a2p" IRQ is also used for notifications from longer running
> operations ?
> 

Yes, it is some sort of work around some platforms implemented as by design
when the SMC returns, the synchronous commands must complete and it is had
to support async SCMI commands without platform specific interrupt(p2a). This
a2p is sort of completion interrupt for synchronous command. I assume the
platform may offload the task from secure f/w to something else otherwise
secure side needs to be given CPU cycles to complete which complicates this.
In short SMC is synchronous and if the execution returns from it in NS world,
the command is complete.

> [...]
> 
> > > > Yes it can be minimalistic but not restrictive. As I already clearly mentioned
> > > > I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
> > > > just mailbox to start with and extend to other transports if and when needed.
> > > > It would be good to impose that restriction in the binding as well but that
> > > > is not a must IMO. I am fine if the bindings for whatever reasons(though I
> > > > don't see the need) to apply for any transport.
> > > So I should simply drop the smc.c changes , keep the rest, and send V2 ?
> > 
> > Not just that. Unless DT maintainers oppose, I just want to keep this
> > new property valid only for mailbox transport(i.e. "arm,scmi" compatible
> > not otherwise) so that we can catch any other use in binding checks and
> > interested parties must discuss on the list and expand that if they require.
> > 
> > Also we can explore if we can parse and scan this in mailbox transport for
> > now.
> I feel that this only adds more implementation complexity and makes the
> solution less generic, while it does win us very little in the end ? The
> generic solution implementation is actually easier to implement.

Yes I want it less generic to start with. Why you want to start making
this workaround on your platform a generic implementation just because
the specification has provision for it ?

-- 
Regards,
Sudeep

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Marek Vasut]

On 12/5/25 10:54 AM, Sudeep Holla wrote:

Hello Sudeep,

>>>>> Also IIUC, the irq request happens
>>>>> as part of channel startup and there are no explicit APIs for the mbox client
>>>>> driver to control that. SCMI is mbox client in this case.
>>>>
>>>> Sure, but the mailbox driver has to make sure it is correctly demuxing the
>>>> IRQs it handles and correctly sends received_data notifications to the right
>>>> channel(s) .
>>>>
>>>
>>> Agreed, but the concern is that if SCMI is forced to use polling when the
>>> channel is opened, and IRQs are enabled by default with no way for SCMI to
>>> disable them in polling mode, we could run into issues.
>>
>> This constellation seems odd -- if the channel can do IRQs, then this
>> property should not be present in DT.
>>
> 
> Yes, but there is no way to validate or check this and that is the root
> cause for all my worries.

Should a configuration like that even be considered valid and relevant ?

>>> I realise it’s a very
>>> specific corner case, but every time I’ve assumed such scenarios wouldn’t
>>> occur, we eventually ended up encountering them. So sorry if I am very
>>> pedantic, but I prefer to start smaller and restrictive and expand if and
>>> when necessary or required only.
>>
>> I don't think this case, where mailbox channel does IRQs and polling is
>> enabled, can/should even be considered valid. Either the channel does not do
>> IRQs and then it should do polling, or it does IRQs and then it should use
>> IRQs, but not both.
>>
> 
> Yes ideally, but having loose ends like this binding which allows someone
> to add it to their DT complicates though it is invalid. We have no way to
> detect and I don't want to work around such configs in the future.

If the DT is invalid, bad things happen, but I would argue that is then 
a DT bug and the DT should be fixed.

[...]

>>> Yes, that’s essential, because polling in an SMC context is meaningless in my
>>> opinion.
>>
>> Maybe the "a2p" IRQ is also used for notifications from longer running
>> operations ?
>>
> 
> Yes, it is some sort of work around some platforms implemented as by design
> when the SMC returns, the synchronous commands must complete and it is had
> to support async SCMI commands without platform specific interrupt(p2a). This
> a2p is sort of completion interrupt for synchronous command. I assume the
> platform may offload the task from secure f/w to something else otherwise
> secure side needs to be given CPU cycles to complete which complicates this.
> In short SMC is synchronous and if the execution returns from it in NS world,
> the command is complete.

Wouldn't polling still be useful for the async case , even in SMC setup?
Note that the SMC setup does use shmem, and therefore can do polling on 
the shmem.

>> [...]
>>
>>>>> Yes it can be minimalistic but not restrictive. As I already clearly mentioned
>>>>> I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
>>>>> just mailbox to start with and extend to other transports if and when needed.
>>>>> It would be good to impose that restriction in the binding as well but that
>>>>> is not a must IMO. I am fine if the bindings for whatever reasons(though I
>>>>> don't see the need) to apply for any transport.
>>>> So I should simply drop the smc.c changes , keep the rest, and send V2 ?
>>>
>>> Not just that. Unless DT maintainers oppose, I just want to keep this
>>> new property valid only for mailbox transport(i.e. "arm,scmi" compatible
>>> not otherwise) so that we can catch any other use in binding checks and
>>> interested parties must discuss on the list and expand that if they require.
>>>
>>> Also we can explore if we can parse and scan this in mailbox transport for
>>> now.
>> I feel that this only adds more implementation complexity and makes the
>> solution less generic, while it does win us very little in the end ? The
>> generic solution implementation is actually easier to implement.
> 
> Yes I want it less generic to start with. Why you want to start making
> this workaround on your platform a generic implementation just because
> the specification has provision for it ?

Because this is generic kernel code, it seems counterintuitive to 
introduce less generic solution which requires more complex implementation.

Since the DEN0056 specification states this mode of operation is 
supported, I also wouldn't call it a workaround.

Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Document arm,poll-transport property

[Sudeep Holla]

On Sun, Dec 07, 2025 at 10:16:36AM +0100, Marek Vasut wrote:
> On 12/5/25 10:54 AM, Sudeep Holla wrote:
> 
> Hello Sudeep,
> 
> > > > > > Also IIUC, the irq request happens
> > > > > > as part of channel startup and there are no explicit APIs for the mbox client
> > > > > > driver to control that. SCMI is mbox client in this case.
> > > > > 
> > > > > Sure, but the mailbox driver has to make sure it is correctly demuxing the
> > > > > IRQs it handles and correctly sends received_data notifications to the right
> > > > > channel(s) .
> > > > > 
> > > > 
> > > > Agreed, but the concern is that if SCMI is forced to use polling when the
> > > > channel is opened, and IRQs are enabled by default with no way for SCMI to
> > > > disable them in polling mode, we could run into issues.
> > > 
> > > This constellation seems odd -- if the channel can do IRQs, then this
> > > property should not be present in DT.
> > > 
> > 
> > Yes, but there is no way to validate or check this and that is the root
> > cause for all my worries.
> 
> Should a configuration like that even be considered valid and relevant ?
> 

Yes, as I have mentioned, there is no way to validate the same in the kernel.

> > > > I realise it’s a very
> > > > specific corner case, but every time I’ve assumed such scenarios wouldn’t
> > > > occur, we eventually ended up encountering them. So sorry if I am very
> > > > pedantic, but I prefer to start smaller and restrictive and expand if and
> > > > when necessary or required only.
> > > 
> > > I don't think this case, where mailbox channel does IRQs and polling is
> > > enabled, can/should even be considered valid. Either the channel does not do
> > > IRQs and then it should do polling, or it does IRQs and then it should use
> > > IRQs, but not both.
> > > 
> > 
> > Yes ideally, but having loose ends like this binding which allows someone
> > to add it to their DT complicates though it is invalid. We have no way to
> > detect and I don't want to work around such configs in the future.
> 
> If the DT is invalid, bad things happen, but I would argue that is then a DT
> bug and the DT should be fixed.
> 

Well, ideally I would like that, but not always the reality.

> [...]
> 
> > > > Yes, that’s essential, because polling in an SMC context is meaningless in my
> > > > opinion.
> > > 
> > > Maybe the "a2p" IRQ is also used for notifications from longer running
> > > operations ?
> > > 
> > 
> > Yes, it is some sort of work around some platforms implemented as by design
> > when the SMC returns, the synchronous commands must complete and it is had
> > to support async SCMI commands without platform specific interrupt(p2a). This
> > a2p is sort of completion interrupt for synchronous command. I assume the
> > platform may offload the task from secure f/w to something else otherwise
> > secure side needs to be given CPU cycles to complete which complicates this.
> > In short SMC is synchronous and if the execution returns from it in NS world,
> > the command is complete.
> 
> Wouldn't polling still be useful for the async case , even in SMC setup?
> Note that the SMC setup does use shmem, and therefore can do polling on the
> shmem.
> 

No, it makes no sense for SMC as I have already mentioned few times.

> > > [...]
> > > 
> > > > > > Yes it can be minimalistic but not restrictive. As I already clearly mentioned
> > > > > > I don't see it makes any sense to enable this for SMC/OPTEE. Lets start with
> > > > > > just mailbox to start with and extend to other transports if and when needed.
> > > > > > It would be good to impose that restriction in the binding as well but that
> > > > > > is not a must IMO. I am fine if the bindings for whatever reasons(though I
> > > > > > don't see the need) to apply for any transport.
> > > > > So I should simply drop the smc.c changes , keep the rest, and send V2 ?
> > > > 
> > > > Not just that. Unless DT maintainers oppose, I just want to keep this
> > > > new property valid only for mailbox transport(i.e. "arm,scmi" compatible
> > > > not otherwise) so that we can catch any other use in binding checks and
> > > > interested parties must discuss on the list and expand that if they require.
> > > > 
> > > > Also we can explore if we can parse and scan this in mailbox transport for
> > > > now.
> > > I feel that this only adds more implementation complexity and makes the
> > > solution less generic, while it does win us very little in the end ? The
> > > generic solution implementation is actually easier to implement.
> > 
> > Yes I want it less generic to start with. Why you want to start making
> > this workaround on your platform a generic implementation just because
> > the specification has provision for it ?
> 
> Because this is generic kernel code, it seems counterintuitive to introduce
> less generic solution which requires more complex implementation.
> 

I would argue. Lot of code gets added as specific and gets generalised
eventually if there are more users and in different configurations.

> Since the DEN0056 specification states this mode of operation is supported,
> I also wouldn't call it a workaround.

Sure, I take back if I called it workaround. But why would we want to make
it generic when we can test only mailbox based platform with it. I don't see
how it can be useful with SMC/Optee. I am not sure if it is useful with
virtio and if there is a way to test this. All I am saying is I don't want to
enable something and advertise it as generic when we have no platform or way
to test it and keep it functionally correct.

-- 
Regards,
Sudeep