[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