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

[PATCH v2 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
shmem based implementations.

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
---
V2: s@mean@&t and limit poll transport to mailbox/shmem only
---
 .../devicetree/bindings/firmware/arm,scmi.yaml         | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index be817fd9cc34b..f4bf4173c5c7e 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 meant to work around uncooperative SCP, which does not generate
+      completion interrupts.
+
   arm,smc-id:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
@@ -379,6 +386,9 @@ then:
     - shmem
 
 else:
+  properties:
+    arm,poll-transport: false
+
   if:
     properties:
       compatible:
-- 
2.51.0

[PATCH v2 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 to mbox/shmem based
implementations.

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

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
---
V2: Drop no IRQ handling from SMC transport and update commit message
---
 drivers/firmware/arm_scmi/common.h | 4 ++++
 drivers/firmware/arm_scmi/driver.c | 4 ++++
 2 files changed, 8 insertions(+)

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,
-- 
2.51.0

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

[Krzysztof Kozlowski]

On Wed, Dec 31, 2025 at 10:29:18PM +0100, Marek Vasut wrote:
> Document new property arm,poll-transport, which sets all SCMI operation into

Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597

> poll mode. This is meant to work around uncooperative SCP implementations,
> which do not generate completion interrupts. This applies primarily on mbox
> shmem based implementations.
> 
> 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
> ---
> V2: s@mean@&t and limit poll transport to mailbox/shmem only
> ---
>  .../devicetree/bindings/firmware/arm,scmi.yaml         | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index be817fd9cc34b..f4bf4173c5c7e 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 meant to work around uncooperative SCP, which does not generate

Also not wrapped.

Anyway, you described the desired Linux feature or behavior, not the
actual hardware. The bindings are about the latter, so instead you need
to rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.


Best regards,
Krzysztof

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

[Sudeep Holla]

On Wed, Dec 31, 2025 at 10:29:19PM +0100, Marek Vasut wrote:
> 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 to mbox/shmem based
> implementations.
> 
> With this property set, such implementations which do not generate interrupts
> can be interacted with, until they are fixed to generate interrupts properly.
> 
> 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
> ---
> V2: Drop no IRQ handling from SMC transport and update commit message
> ---
>  drivers/firmware/arm_scmi/common.h | 4 ++++
>  drivers/firmware/arm_scmi/driver.c | 4 ++++
>  2 files changed, 8 insertions(+)
> 
> 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;

My preference would be to reuse `force_polling` for this. We need to drop
const but that should be OK. Anyways I would like to know if Cristian thinks
otherwise for any reasons I might be missing to see.

-- 
Regards,
Sudeep

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

[Cristian Marussi]

On Mon, Jan 12, 2026 at 12:06:11PM +0000, Sudeep Holla wrote:
> On Wed, Dec 31, 2025 at 10:29:19PM +0100, Marek Vasut wrote:
> > 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 to mbox/shmem based
> > implementations.
> > 
> > With this property set, such implementations which do not generate interrupts
> > can be interacted with, until they are fixed to generate interrupts properly.
> > 
> > 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
> > ---
> > V2: Drop no IRQ handling from SMC transport and update commit message
> > ---
> >  drivers/firmware/arm_scmi/common.h | 4 ++++
> >  drivers/firmware/arm_scmi/driver.c | 4 ++++
> >  2 files changed, 8 insertions(+)
> > 
> > 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;
> 
> My preference would be to reuse `force_polling` for this. We need to drop
> const but that should be OK. Anyways I would like to know if Cristian thinks
> otherwise for any reasons I might be missing to see.

I would rather keep the 2 things separate since force_polling is more of
a brutal low level debug/test facility and, even though it basically
produces the same result as the new @no_completion_irq, if we remove it
and unify it in a single boolean that can be overriden from the DT we end
up in a situation in which we cannot anymore easily force_polling by
switching the flag in the code since it could be overridden by a
conflicting 'arm,poll-transport' DT setup. (and you have to patch DT
for testing)

So if we have one single underlying boolean (e.g. 'poll') and by any chance
we end up with a DT containing:

	arm,poll-transport = false

we cannot anymore override the condition by forcing in the code

	poll = true,

since it would be switfly overridden by the DT prop.

Also semantically force_polling express much more the situation.

Anyway...I may be overthinking or missing something.

Cheers,
Cristian

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

[Sudeep Holla]

On Mon, Jan 12, 2026 at 12:53:54PM +0000, Cristian Marussi wrote:
> On Mon, Jan 12, 2026 at 12:06:11PM +0000, Sudeep Holla wrote:
> > On Wed, Dec 31, 2025 at 10:29:19PM +0100, Marek Vasut wrote:
> > > 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 to mbox/shmem based
> > > implementations.
> > > 
> > > With this property set, such implementations which do not generate interrupts
> > > can be interacted with, until they are fixed to generate interrupts properly.
> > > 
> > > 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
> > > ---
> > > V2: Drop no IRQ handling from SMC transport and update commit message
> > > ---
> > >  drivers/firmware/arm_scmi/common.h | 4 ++++
> > >  drivers/firmware/arm_scmi/driver.c | 4 ++++
> > >  2 files changed, 8 insertions(+)
> > > 
> > > 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;
> > 
> > My preference would be to reuse `force_polling` for this. We need to drop
> > const but that should be OK. Anyways I would like to know if Cristian thinks
> > otherwise for any reasons I might be missing to see.
> 
> I would rather keep the 2 things separate since force_polling is more of
> a brutal low level debug/test facility and, even though it basically
> produces the same result as the new @no_completion_irq, if we remove it
> and unify it in a single boolean that can be overriden from the DT we end
> up in a situation in which we cannot anymore easily force_polling by
> switching the flag in the code since it could be overridden by a
> conflicting 'arm,poll-transport' DT setup. (and you have to patch DT
> for testing)
> 
> So if we have one single underlying boolean (e.g. 'poll') and by any chance
> we end up with a DT containing:
> 
> 	arm,poll-transport = false
> 
> we cannot anymore override the condition by forcing in the code
> 
> 	poll = true,
> 
> since it would be switfly overridden by the DT prop.
> 
> Also semantically force_polling express much more the situation.
> 
> Anyway...I may be overthinking or missing something.
>

Understood, looking at raw I did get a sense of this but didn't spend much
time and thought of asking you. So, all good. Let's not mix them together
then. Thanks for the details!

-- 
Regards,
Sudeep

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

[Sudeep Holla]

On Fri, Jan 02, 2026 at 12:39:12PM +0100, Krzysztof Kozlowski wrote:
> On Wed, Dec 31, 2025 at 10:29:18PM +0100, Marek Vasut wrote:
> > Document new property arm,poll-transport, which sets all SCMI operation into
> 
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> 
> > poll mode. This is meant to work around uncooperative SCP implementations,
> > which do not generate completion interrupts. This applies primarily on mbox
> > shmem based implementations.
> > 
> > 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
> > ---
> > V2: s@mean@&t and limit poll transport to mailbox/shmem only
> > ---
> >  .../devicetree/bindings/firmware/arm,scmi.yaml         | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> > index be817fd9cc34b..f4bf4173c5c7e 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 meant to work around uncooperative SCP, which does not generate
> 
> Also not wrapped.
> 
> Anyway, you described the desired Linux feature or behavior, not the
> actual hardware. The bindings are about the latter, so instead you need
> to rephrase the property and its description to match actual hardware
> capabilities/features/configuration etc.
> 

I agree with this assessment. Rephrasing the property to reflect the actual
hardware/firmware characteristics makes more sense. Something along the lines
of `arm,no-completion-interrupt`, or a similar name, would better capture the
underlying reality, namely that the platform or firmware does not generate a
completion interrupt without encoding OS-specific policy or behavior.

-- 
Regards,
Sudeep