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

[Marek Vasut <marek.vasut@mailbox.org>]

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