[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