All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Stefan Agner <stefan@agner.ch>,
	linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH v2 1/2] arch: m68k: Add definitions for flash NFC support
Date: Tue, 2 Jul 2024 18:44:52 +0200	[thread overview]
Message-ID: <b974df45-daf5-4156-8532-cf9e2be8bdfa@yoseli.org> (raw)
In-Reply-To: <20240628094511.75cc9c78@xps-13>

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

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Stefan Agner <stefan@agner.ch>,
	linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH v2 1/2] arch: m68k: Add definitions for flash NFC support
Date: Tue, 2 Jul 2024 18:44:52 +0200	[thread overview]
Message-ID: <b974df45-daf5-4156-8532-cf9e2be8bdfa@yoseli.org> (raw)
In-Reply-To: <20240628094511.75cc9c78@xps-13>

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2024-07-02 16:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 16:05 [PATCH v2 0/2] M5441x: Add NFC support Jean-Michel Hautbois
2024-06-27 16:05 ` Jean-Michel Hautbois
2024-06-27 16:05 ` [PATCH v2 1/2] arch: m68k: Add definitions for flash " Jean-Michel Hautbois
2024-06-27 16:05   ` Jean-Michel Hautbois
2024-06-28  7:45   ` Miquel Raynal
2024-06-28  7:45     ` Miquel Raynal
2024-07-02 16:44     ` Jean-Michel Hautbois [this message]
2024-07-02 16:44       ` Jean-Michel Hautbois
2024-07-03 13:30       ` Greg Ungerer
2024-07-03 13:30         ` Greg Ungerer
2024-07-03 14:55         ` Miquel Raynal
2024-07-03 14:55           ` Miquel Raynal
2024-06-27 16:05 ` [PATCH v2 2/2] mtd: nand: Add support for M5441x NFC Jean-Michel Hautbois
2024-06-27 16:05   ` Jean-Michel Hautbois
2024-06-29 18:25   ` kernel test robot
2024-06-29 18:25     ` kernel test robot
2024-07-01 17:48   ` kernel test robot
2024-07-01 17:48     ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b974df45-daf5-4156-8532-cf9e2be8bdfa@yoseli.org \
    --to=jeanmichel.hautbois@yoseli.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=stefan@agner.ch \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.