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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ?

[...]



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux