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

[Marek Vasut]

On 12/8/25 5:30 PM, Sudeep Holla wrote:

Hello Sudeep,

it seems I missed you at LPC, we could have discussed this in there, 
pity ...

>>>>>>> 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) .
>>>>>>
>>>>>
>>>>> Agreed, but the concern is that if SCMI is forced to use polling when the
>>>>> channel is opened, and IRQs are enabled by default with no way for SCMI to
>>>>> disable them in polling mode, we could run into issues.
>>>>
>>>> This constellation seems odd -- if the channel can do IRQs, then this
>>>> property should not be present in DT.
>>>>
>>>
>>> Yes, but there is no way to validate or check this and that is the root
>>> cause for all my worries.
>>
>> Should a configuration like that even be considered valid and relevant ?
>>
> 
> Yes, as I have mentioned, there is no way to validate the same in the kernel.

But the DT has to be a valid hardware description. If your DT is not a 
valid hardware description, bad things can and likely will happen.

I would argue that if you add this poll property into DT, then the DT 
has to describe hardware which does not generate IRQs, otherwise the DT 
is invalid.

The poll property description in this binding document already states 
that this is for hardware which does not generate IRQs.

>>>>> I realise it’s a very
>>>>> specific corner case, but every time I’ve assumed such scenarios wouldn’t
>>>>> occur, we eventually ended up encountering them. So sorry if I am very
>>>>> pedantic, but I prefer to start smaller and restrictive and expand if and
>>>>> when necessary or required only.
>>>>
>>>> I don't think this case, where mailbox channel does IRQs and polling is
>>>> enabled, can/should even be considered valid. Either the channel does not do
>>>> IRQs and then it should do polling, or it does IRQs and then it should use
>>>> IRQs, but not both.
>>>>
>>>
>>> Yes ideally, but having loose ends like this binding which allows someone
>>> to add it to their DT complicates though it is invalid. We have no way to
>>> detect and I don't want to work around such configs in the future.
>>
>> If the DT is invalid, bad things happen, but I would argue that is then a DT
>> bug and the DT should be fixed.
>>
> 
> Well, ideally I would like that, but not always the reality.

If the DT (hardware description) is invalid, Linux can only do so much 
about it. And it is up to the implementer of such a broken DT to fix 
that DT.

If there is a broken hardware with this poll property in DT which 
suddenly does also generate IRQs and those cannot be disabled, then that 
can likely be quirked out and such IRQs can be ignored by some empty IRQ 
handler. But I would also argue that such a quirk should be added only 
once such a broken hardware gets upstreamed (if ever).

>> [...]
>>
>>>>> Yes, that’s essential, because polling in an SMC context is meaningless in my
>>>>> opinion.
>>>>
>>>> Maybe the "a2p" IRQ is also used for notifications from longer running
>>>> operations ?
>>>>
>>>
>>> Yes, it is some sort of work around some platforms implemented as by design
>>> when the SMC returns, the synchronous commands must complete and it is had
>>> to support async SCMI commands without platform specific interrupt(p2a). This
>>> a2p is sort of completion interrupt for synchronous command. I assume the
>>> platform may offload the task from secure f/w to something else otherwise
>>> secure side needs to be given CPU cycles to complete which complicates this.
>>> In short SMC is synchronous and if the execution returns from it in NS world,
>>> the command is complete.
>>
>> Wouldn't polling still be useful for the async case , even in SMC setup?
>> Note that the SMC setup does use shmem, and therefore can do polling on the
>> shmem.
>>
> 
> No, it makes no sense for SMC as I have already mentioned few times.

I can drop the SMC part from the 2/2 , but it feels like we're dropping 
a poll coverage for the async part.

>>>> [...]
>>>>
>>>>>>> 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 ?
>>>>>
>>>>> Not just that. Unless DT maintainers oppose, I just want to keep this
>>>>> new property valid only for mailbox transport(i.e. "arm,scmi" compatible
>>>>> not otherwise) so that we can catch any other use in binding checks and
>>>>> interested parties must discuss on the list and expand that if they require.
>>>>>
>>>>> Also we can explore if we can parse and scan this in mailbox transport for
>>>>> now.
>>>> I feel that this only adds more implementation complexity and makes the
>>>> solution less generic, while it does win us very little in the end ? The
>>>> generic solution implementation is actually easier to implement.
>>>
>>> Yes I want it less generic to start with. Why you want to start making
>>> this workaround on your platform a generic implementation just because
>>> the specification has provision for it ?
>>
>> Because this is generic kernel code, it seems counterintuitive to introduce
>> less generic solution which requires more complex implementation.
>>
> 
> I would argue. Lot of code gets added as specific and gets generalised
> eventually if there are more users and in different configurations.
> 
>> Since the DEN0056 specification states this mode of operation is supported,
>> I also wouldn't call it a workaround.
> 
> Sure, I take back if I called it workaround. But why would we want to make
> it generic when we can test only mailbox based platform with it. I don't see
> how it can be useful with SMC/Optee.

For SMC, I have no use case, but it seems like the async interrupt could 
benefit from polling if ever needed.

> I am not sure if it is useful with
> virtio and if there is a way to test this. All I am saying is I don't want to
> enable something and advertise it as generic when we have no platform or way
> to test it and keep it functionally correct.
All right, let me send a slightly reduced V2 to move this along.