[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 ?