From: Mason <slash.tmp@free.fr>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Brian Norris <computersforpeace@gmail.com>,
Sebastian Frias <sf84@laposte.net>,
David Woodhouse <dwmw2@infradead.org>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: RFC on large number of hacks in mtd core files
Date: Thu, 28 Jan 2016 22:05:49 +0100 [thread overview]
Message-ID: <56AA82AD.2020808@free.fr> (raw)
In-Reply-To: <CAMuHMdVEVmf_kSknPSkYUBkaemfcXP6HXorkjEayC6zR5-s_yw@mail.gmail.com>
On 28/01/2016 19:05, Geert Uytterhoeven wrote:
> On Mon, Jan 25, 2016 at 6:34 PM, Mason <slash.tmp@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.
next prev parent reply other threads:[~2016-01-28 21:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 15:34 RFC on large number of hacks in mtd core files Mason
2016-01-23 3:16 ` Brian Norris
2016-01-23 10:53 ` Mason
2016-01-25 17:34 ` Mason
2016-01-28 18:05 ` Geert Uytterhoeven
2016-01-28 21:05 ` Mason [this message]
2016-01-29 7:50 ` Geert Uytterhoeven
2016-01-29 16:27 ` Boris Brezillon
2016-01-29 18:14 ` Brian Norris
2016-01-30 11:37 ` Boris Brezillon
2016-01-29 23:25 ` Mason
2016-01-30 11:22 ` Boris Brezillon
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=56AA82AD.2020808@free.fr \
--to=slash.tmp@free.fr \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=geert@linux-m68k.org \
--cc=linux-mtd@lists.infradead.org \
--cc=sf84@laposte.net \
/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.