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

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

 



Hi Marek

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@xxxxxxx>
---
Cc: Alexandre Torgue <alexandre.torgue@xxxxxxxxxxx>
Cc: Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>
Cc: Maxime Coquelin <mcoquelin.stm32@xxxxxxxxx>
Cc: Richard Cochran <richardcochran@xxxxxxxxx>
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: devicetree@xxxxxxxxxxxxxxx
Cc: kernel@xxxxxxxxxxxxxxxxxx
Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Cc: linux-stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
---
  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@xxxxxxx/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.

Regards
Alex






[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