diff mbox series

[v2,1/2] arch: m68k: Add definitions for flash NFC support

Message ID 20240627-upstream-nfc-mcf5441x-v2-1-312929d09ee5@yoseli.org
State New
Headers show
Series M5441x: Add NFC support | expand

Commit Message

Jean-Michel Hautbois June 27, 2024, 4:05 p.m. UTC
Add a few definitions, as the base address for the NFC for the M5441x.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 arch/m68k/include/asm/m5441xsim.h | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Miquel Raynal June 28, 2024, 7:45 a.m. UTC | #1
Hi Jean-Michel & Geert,

jeanmichel.hautbois@yoseli.org 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@yoseli.org>
> ---
>  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,
Miquèl
Jean-Michel Hautbois July 2, 2024, 4:44 p.m. UTC | #2
Hi Miquel,

On 28/06/2024 09:45, Miquel Raynal wrote:
> Hi Jean-Michel & Geert,
> 
> jeanmichel.hautbois@yoseli.org 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@yoseli.org>
>> ---
>>   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
Greg Ungerer July 3, 2024, 1:30 p.m. UTC | #3
On 3/7/24 02:44, Jean-Michel Hautbois wrote:
> Hi Miquel,
> 
> On 28/06/2024 09:45, Miquel Raynal wrote:
>> Hi Jean-Michel & Geert,
>>
>> jeanmichel.hautbois@yoseli.org 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@yoseli.org>
>>> ---
>>>   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).

It would be nice to use devicetrees on ColdFire, but I am not aware of anyone
currently working on it. So I don't think we will see it any time soon.
So currently all supported ColdFire peripherals are "legacy" and use the
old platform model.


> AFAIK the platform data is not officialy considered deprecated ? As it concerns a few platforms out there...

Certainly not officially deprecated. m68k in all its forms is currently well maintained
(if not necessarily a lot of new development).

Regards
Greg
Miquel Raynal July 3, 2024, 2:55 p.m. UTC | #4
Hi Greg,

gerg@kernel.org wrote on Wed, 3 Jul 2024 23:30:09 +1000:

> On 3/7/24 02:44, Jean-Michel Hautbois wrote:
> > Hi Miquel,
> > 
> > On 28/06/2024 09:45, Miquel Raynal wrote:  
> >> Hi Jean-Michel & Geert,
> >>
> >> jeanmichel.hautbois@yoseli.org 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@yoseli.org>
> >>> ---
> >>>   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).  
> 
> It would be nice to use devicetrees on ColdFire, but I am not aware of anyone
> currently working on it. So I don't think we will see it any time soon.
> So currently all supported ColdFire peripherals are "legacy" and use the
> old platform model.

It's not the old platform model, it is older than the old platform
model. This series hardcodes a physical offset in a driver. We are not
even talking about a C structure defining platform data.

> > AFAIK the platform data is not officialy considered deprecated ? As it concerns a few platforms out there...  
> 
> Certainly not officially deprecated. m68k in all its forms is currently well maintained
> (if not necessarily a lot of new development).

The platform is not deprecated, it is even maintained, but saying that
hardware support using plain C structures and machine drivers is
deprecated doesn't hurt me.

Thanks,
Miquèl
diff mbox series

Patch

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)
 #endif /* m5441xsim_h */