RFC on large number of hacks in mtd core files

[Mason]

On 28/01/2016 19:05, Geert Uytterhoeven wrote:

> On Mon, Jan 25, 2016 at 6:34 PM, Mason <slash.tmp at free.fr> wrote:
>
>> OK, here's my second attempt at presenting the information.
>> I'm grateful if anyone has comments regarding the changes
>> in core files, or even the driver itself.
> 
> One general comment: all these #ifdef CONFIG_TANGOX / #else / #endif
> constructs do not cope well with multi-platform kernels.
> The same is true for the CONFIG_MTD_NAND_BBM.

First of all, thanks for taking a look at the awful patch
I sent. I just want to stress that I have no intention of
submitting anything like this.

Perhaps it would help if I asked specific questions.

About devices/m25p80.c : the header mentions
"MTD SPI driver for ST M25Pxx (and similar) serial flash chips"

I don't know anything about SPI. Is SPI the bus connecting
Flash chips to the Flash controller?

If Brian's comment that I can ignore changes outside mtd/nand
is correct, then I should only need to focus on
mtd/nand/nand_base.c and mtd/nand/nand_ids.c

What about those NAND_MFR defines?

+#define NAND_MFR_ESMT		0x92
+#define NAND_MFR_MIRA		0xc8

I see that include/linux/mtd/nand.h has

#define NAND_MFR_EON            0x92

ESMT apparently stands for
Elite Semiconductor Memory Technology Inc
Apparently ESMT bought Eon a few months ago.
http://technews.co/2015/11/11/taiwans-elite-semiconductor-to-absorb-rival-eon-silicon/

So I guess it's expected that these two manufacturers
share the same ID?

As for the MIRA ID... Looks like this patch is relevant:
http://lists.infradead.org/pipermail/linux-mtd/2014-December/056765.html
+#define NAND_MFR_GIGADEVICE	0xc8


BTW, did you guys see the awful bug in the nand_ids.c part?
Several whitespace-only strings were added, with the intent
of writing them at run-time! But I'll bet the compiler uses
the same array for all of them.

Regards.