From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: "\"Qi Wang 王起 (qiwang)\"" <qiwang@micron.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"arnaud.mouiche@invoxia.com" <arnaud.mouiche@invoxia.com>,
"Brian Norris" <computersforpeace@gmail.com>
Cc: "ionela.voinescu@imgtec.com" <ionela.voinescu@imgtec.com>,
James Hartley <james.hartley@imgtec.com>
Subject: Re: [PATCH 0/2] staging: mtd: Support for GigaDevice SPI NAND flash
Date: Fri, 21 Nov 2014 08:51:48 -0300 [thread overview]
Message-ID: <546F2754.6090509@imgtec.com> (raw)
In-Reply-To: <71CF8D7F32C5C24C9CD1D0E02D52498A7713225E@NTXXIAMBX02.xacn.micron.com>
On 11/20/2014 10:16 PM, Qi Wang 王起 (qiwang) wrote:
>> On 11/20/2014 10:18 AM, Ezequiel Garcia wrote:
>> Hm, perhaps it's better to rely in the NAND core code and avoid that BBT
>> and ECC code handling duplication?
>>
>> Ionela and I are preparing an SPI NAND framework, but it's far from
>> ready yet, so if you have something to submit, please do so :)
>
> Yes, duplicate BBT and ECC code from nand code do is not a good idea.
> But SPI NAND framework should be a standalone module in MTD, might cause
> chaos if it still rely on NAND core code, that is my only concern.
Any reasons why you think it should be a standalone MTD driver?
Why do you say it'd case chaos?
> How do you think?
>
Yeah, I've been thinking about this for some time. Right now, I think that
SPI NAND is just that: a NAND over SPI, so I'm doing some experiments
around this design:
Userspace
------------------
MTD
------------------
NAND core
------------------
SPI NAND core
------------------
SPI NAND device
------------------
SPI core
------------------
SPI master
------------------
Hardware
--
Ezequiel
next prev parent reply other threads:[~2014-11-21 11:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.22397.1416508326.22890.linux-mtd@lists.infradead.org>
2014-11-21 1:16 ` [PATCH 0/2] staging: mtd: Support for GigaDevice SPI NAND flash Qi Wang 王起 (qiwang)
2014-11-21 9:24 ` arnaud.mouiche
2014-11-21 11:51 ` Ezequiel Garcia [this message]
2014-11-20 8:39 bpqw
2014-11-20 13:18 ` Ezequiel Garcia
2014-11-25 7:02 ` bpqw
2014-11-25 16:59 ` Ezequiel Garcia
-- strict thread matches above, loose matches on Subject: below --
2014-11-06 15:51 Ionela Voinescu
2014-11-06 16:05 ` Greg KH
2014-11-06 17:32 ` Ionela Voinescu
2014-11-06 17:44 ` Greg KH
2014-11-06 18:03 ` Ionela Voinescu
2014-11-06 18:17 ` Ezequiel Garcia
2014-11-06 19:20 ` Brian Norris
2014-11-07 13:00 ` Ionela Voinescu
2014-11-10 9:00 ` arnaud.mouiche
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=546F2754.6090509@imgtec.com \
--to=ezequiel@vanguardiasur.com.ar \
--cc=arnaud.mouiche@invoxia.com \
--cc=computersforpeace@gmail.com \
--cc=ionela.voinescu@imgtec.com \
--cc=james.hartley@imgtec.com \
--cc=linux-mtd@lists.infradead.org \
--cc=qiwang@micron.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).