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

[Arnaud POULIQUEN]

> -----Original Message-----
> From: Marek Vasut <marex at denx.de>
> Sent: Tuesday, June 6, 2023 7:28 PM
> 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/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 ?

It has been introduced mainly to test the detach feature,
on a second platform to help remoteproc maintainers for the review
process. But the feature is not fully implemented on stm32mp1
( auto reboot of thye M4 on crash, appropriate resource table clean-up,...)
I would prefer to remove it in ST board DT than add it in the DTSI.
That said as mentioned for legacy support, better to keep for ST board.

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

The inverse it true, User can add it in their DT if really need.

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

Everything could be possible...
Once can want to replace the shutdown mailbox by the detach. 
Once can also build demo using the detach mailbox channel for another purpose.

I quite confuse why you insist to declare this detach mailbox in the DTSI?
Is there a strong constraint on your side?

Regards,
Arnaud

> 
> [...]