[Linux-stm32] [PATCH 1/5] ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon

[Marek Vasut]

On 6/1/23 14:56, Arnaud POULIQUEN wrote:

Hi,

[...]

>> I assume that if the firmware does not use the detach mailbox, then the
>> detach mailbox is just ignored and unused, so there is no problem with
>> having it described in the DT in any case ?
> 
> Yes, The aim of the ST evaluation board is to provide a DT  to a support
> different firmwares for demo and tests.  But it is not the case of all boards...
> If your boards provide demo using the "detach" it is justified.
> If you just add it as a workaround to mask the warnings, you just mask the issue.

Then it seems there is no issue with the boards modified here, because 
as far as I can tell, those are all general purpose SoMs and evaluation 
boards. With such systems, you cannot predict what the user would like 
to use those for, that could include whatever ST demo.

>> And if that's the case, then I would much rather prefer to have all the boards
>> describe the same set of mailboxes, so they don't diverge . What do you
>> think ?
>>
> 
> I would avoid this.  It is only a configuration by default for current demo.

That current demo is restricted to ST produced boards only, or can it 
also be run on development kits manufactured by other vendors ? I think 
it is the later, and I don't see why those should be kept out.

> The allocation depends on the firmware loaded on M4, so depend on the project.
> For instance, a work has started in OpenAMP community to implement the vIrtio Services
> For the IPC.  Each virtio services would be associated to one or several mailbox
> Channels.  In this case we would need to arbitrate allocations.
> The result could be that we propose a virtio channel for rpmsg + some other virtio.
> More than that we probably manage the mailboxes in sub node
> Here is an RFC on the topic (https://lore.kernel.org/lkml/20220920202201.GB1042164@p14s/)
> 
> That said, fixing rpmsg virqueue and the shutdown mailboxes in the  SoC dtsi, seems reasonable as it
> provides the default expected implementation.
> Do the same for the detach that is optional and mainly unused, I'm not fan.
> Adding the detach mailbox in the DT to mask a warning issue, I'm rather against it

Removal of divergence.

>>> Rather than adding unused optional mailbox, I will more in favor of
>>> having a mbox_request_channel_byname_optional helper or something
>>> similar
>>
>> See above, I think it is better to have the mailbox described in DT always and
>> not use it (the user can always remove it), than to not have it described on
>> some boards and have it described on other boards (inconsistency).
> 
> Adding it in the DT ( and especially in the Soc DTSI) can also be interpreted as
> "it is defined so you must use it". I would expect that the Bindings already provide
> the information to help user to add it on need.

Why should every single board add it separately and duplicate the same 
stuff, if they can all start with it, and if anyone needs to tweak the 
mailbox allocation, then they can do that in the board DT ? I really 
don't like the duplication suggestion here.