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

[Arnaud POULIQUEN]

Hi,

> -----Original Message-----
> From: Marek Vasut <marex at denx.de>
> Sent: Friday, June 2, 2023 4:36 AM
> To: Arnaud POULIQUEN <arnaud.pouliquen at st.com>; linux-arm-
> kernel at lists.infradead.org
> Cc: devicetree at vger.kernel.org; Conor Dooley <conor+dt at kernel.org>;
> Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Richard Cochran
> <richardcochran at gmail.com>; Rob Herring <robh+dt at kernel.org>; Maxime
> Coquelin <mcoquelin.stm32 at gmail.com>; linux-stm32 at st-md-
> mailman.stormreply.com; kernel at dh-electronics.com
> Subject: Re: [Linux-stm32] [PATCH 1/5] ARM: dts: stm32: Add missing detach
> mailbox for emtrion emSBC-Argon
> 
> 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.[] 

ST Demos are boards dependent.

> 
> > 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.

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.

Regards,
Arnaud