> -----Original Message----- > From: Marek Vasut <marex@xxxxxxx> > Sent: Tuesday, June 6, 2023 7:28 PM > 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/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 > > [...]
