[PATCH] ARM: dts: stm32: Deduplicate rproc mboxes and IRQs

[Marek Vasut]

On 6/27/24 12:48 PM, Alexandre TORGUE wrote:
> Hi Marek

Hi,

> On 6/23/24 21:49, Marek Vasut wrote:
>> Pull mboxes, mbox-names, interrupt-parent, interrupts properties of the
>> m4_rproc into stm32mp151.dtsi to deduplicate multiple copies of the same
>> in multiple board files. Worse, those copies were starting to get out of
>> sync, so this should prevent any such issues in the future.
>>
>> Signed-off-by: Marek Vasut <marex at denx.de>
>> ---
>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
>> Cc: Conor Dooley <conor+dt at kernel.org>
>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>> Cc: Richard Cochran <richardcochran at gmail.com>
>> Cc: Rob Herring <robh+dt at kernel.org>
>> Cc: devicetree at vger.kernel.org
>> Cc: kernel at dh-electronics.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-stm32 at st-md-mailman.stormreply.com
>> ---
>>   arch/arm/boot/dts/st/stm32mp151.dtsi                        | 4 ++++
>>   arch/arm/boot/dts/st/stm32mp157a-icore-stm32mp1.dtsi        | 2 --
>>   arch/arm/boot/dts/st/stm32mp157a-microgea-stm32mp1.dtsi     | 2 --
>>   arch/arm/boot/dts/st/stm32mp157c-ed1.dts                    | 4 ----
>>   arch/arm/boot/dts/st/stm32mp157c-emstamp-argon.dtsi         | 4 ----
>>   arch/arm/boot/dts/st/stm32mp157c-odyssey-som.dtsi           | 4 ----
>>   arch/arm/boot/dts/st/stm32mp157c-phycore-stm32mp15-som.dtsi | 4 ----
>>   arch/arm/boot/dts/st/stm32mp15xx-dhcom-som.dtsi             | 4 ----
>>   arch/arm/boot/dts/st/stm32mp15xx-dhcor-som.dtsi             | 4 ----
>>   arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi                   | 4 ----
>>   arch/arm/boot/dts/st/stm32mp15xx-osd32.dtsi                 | 4 ----
>>   11 files changed, 4 insertions(+), 36 deletions(-)
>>
> ...
> 
> It is an old story we already discussed in the past:
> 
> https://lore.kernel.org/linux-arm-kernel/81f4574d-38c2-21f2-b947-d13e5fc99c60@denx.de/T/#mef3a4050ab4ff181416fe5681f1d5cb9fb744573
> 
> My position remains the same. Those interrupts depends on your 
> system/firmware you plan to use. So we give one example in our ST board 
> which relies on firmware we load in OpenSTLinux. But it is just an 
> example. For example depending the firmware used, the detach could be 
> used or not.
> 
> So I would prefer to not take it.

Ugh, I had it in my upstreaming tree so I resubmitted it, lemme drop it.

Thanks for the reminder and constant vigilance.