Hi, > -----Original Message----- > From: Marek Vasut <marex@xxxxxxx> > Sent: Friday, June 2, 2023 4:36 AM > To: Arnaud POULIQUEN <arnaud.pouliquen@xxxxxx>; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx > Cc: devicetree@xxxxxxxxxxxxxxx; Conor Dooley <conor+dt@xxxxxxxxxx>; > Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Richard Cochran > <richardcochran@xxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Maxime > Coquelin <mcoquelin.stm32@xxxxxxxxx>; linux-stm32@st-md- > mailman.stormreply.com; kernel@xxxxxxxxxxxxxxxxxx > 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
