Hi Miquel,
On 28/06/2024 09:45, Miquel Raynal wrote:
Hi Jean-Michel & Geert,
jeanmichel.hautbois@xxxxxxxxxx wrote on Thu, 27 Jun 2024 18:05:28 +0200:
Add a few definitions, as the base address for the NFC for the M5441x.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@xxxxxxxxxx>
---
arch/m68k/include/asm/m5441xsim.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index f48cf63bd782..d4ee1eab7c4a 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -99,6 +99,7 @@
#define MCFINT2_PIT1 14
#define MCFINT2_PIT2 15
#define MCFINT2_PIT3 16
+#define MCFINT2_NFC 25
#define MCFINT2_RTC 26
/*
@@ -333,4 +334,10 @@
#define MCF_IRQ_BOFF1 (MCFINT1_VECBASE + MCFINT1_FLEXCAN1_BOFF)
#define MCF_IRQ_ERR1 (MCFINT1_VECBASE + MCFINT1_FLEXCAN1_ERR)
+/*
+ * Flash module
+ */
+#define MCF_NFC_BASE 0xfc0fc000
+#define MCF_NFC_SIZE (0xfc0fff3b - 0xfc0fc000)
+#define MCF_NFC_ISR (MCFINT2_VECBASE + MCFINT2_NFC)
I'm sorry but this feels really backwards. Platform data as C
structures are already legacy, but defining these information in
some arch headers and using them directly from drivers really seems
even "wronger" to me. What's the mid/long term plan for this? If the
platforms are still in use today and need to be maintained, why not
finally enabling device tree support? I know it's harder to do than to
say, but I'd like some really good explanation on why we should accept
to do this in 2024 because it feels rather inadequate.
Thanks for your review !
I agree with you it is legacy. I use a lot of ARM platforms and
device-tree is indeed great. Though, switching the m68k architecture to
use this sounds really tough.
I will obviously let Geert and maybe others answer, but my feeling is it
is not really worth it to implement the dts on those platforms are they
are not that used (compared, again, to ARM for instance).
AFAIK the platform data is not officialy considered deprecated ? As it
concerns a few platforms out there...
Thanks,
JM
