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

[Marek Vasut]

On 6/6/23 18:21, Arnaud POULIQUEN wrote:
> Hi,

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.[]
> 
> ST Demos are boards dependent.

I was under the impression those demos can be built from this CubeMX 
stuff for any board, all you need is the CubeMX BSP ?

[...]

>>>>> 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.
> 
> I was speaking about "detach mailbox. Here is what I would like to propose to
> you
> 
> 1)  move all the mailbox declaration in the DTSI except "detach"
> 2) don't declare "detach" in boards DTS ( except ST board for legacy compliance)
> 3) as a next step we will have to fix the unexpected warning on the
>     "detach" mailbox.

Why not make the mailbox available by default on all boards ?

As far as I can tell, if the software is not using the detach mailbox, 
there is no downside, it would just be unused. User can always remove it 
in their DT if really needed.

I believe once can build demos using the detach mailbox for boards with 
stm32mp15xx not manufactured by ST, correct ?

[...]