From: Brian Norris <computersforpeace@gmail.com>
To: punnaiah choudary kalluri <punnaia@xilinx.com>
Cc: Richard Weinberger <richard@nod.at>,
Ben Shelton <ben.shelton@ni.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@xilinx.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>
Subject: Re: [PATCH 1/3] mtd: nand: Add on-die ECC support
Date: Mon, 27 Apr 2015 20:22:13 -0700 [thread overview]
Message-ID: <20150428032213.GI19571@brian-ubuntu> (raw)
In-Reply-To: <CAGnW=BYVn5quNKooiB44CiCYtuYckWArTkft4BQLxs188FwUpg@mail.gmail.com>
On Tue, Apr 28, 2015 at 08:18:12AM +0530, punnaiah choudary kalluri wrote:
> On Tue, Apr 28, 2015 at 4:53 AM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> > On Tue, Apr 28, 2015 at 12:19:16AM +0200, Richard Weinberger wrote:
> >> Oh, I thought every driver has to implement that function. ;-\
> >
> > Nope.
> >
> >> But you're right there is a corner case.
> >
> > And it's not the only one! Right now, there's no guarantee even that
> > read_buf() returns raw data, unmodified by the SoC's controller. Plenty
> > of drivers actually have HW-enabled ECC turned on by default, and so
> > they override the chip->ecc.read_page() (and sometimes
> > chip->ecc.read_page_raw() functions, if we're lucky) with something
> > that pokes the appropriate hardware instead. I expect anything
> > comprehensive here is probably going to have to utilize
> > chip->ecc.read_page_raw(), at least if it's provided by the hardware
> > driver.
>
> Yes, overriding the chip->ecc.read_page_raw would solve this.
I'm actually suggesting that (in this patch set, for on-die ECC
support), maybe we *shouldn't* override chip->ecc.read_page_raw() and
leave that to be defined by the driver, and then on-die ECC support
should be added in a way that just calls chip->ecc.read_page_raw(). This
should work for any driver that already properly supports the raw
callbacks.
> Agree that
> read_buf need not be returning raw data always including my new driver for
> arasan nand flash controller.
I agree with that. At the moment, chip->read_buf() really has very
driver-specific meaning. Not sure if that's really a good thing, but
it's the way things are...
> http://lkml.iu.edu/hypermail/linux/kernel/1504.2/00313.html
In the half a minute I just spent looking at this (I may review it
properly later), I noted a few things:
1. you don't implement ecc.read_page_raw(); this means we'll probably
have trouble supporting on-die ECC with your driver, among other things
2. your patch is all white-space mangled. Please use your favorite
search engine to figure out how to get that right. git-send-email is
your friend.
Thanks,
Brian
next prev parent reply other threads:[~2015-04-28 3:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 14:02 [RFC] On-die ECC support Richard Weinberger
2015-03-25 14:02 ` [PATCH 1/3] mtd: nand: Add on-die " Richard Weinberger
2015-03-25 20:39 ` Paul Bolle
2015-04-27 21:35 ` Ben Shelton
2015-04-27 22:19 ` Richard Weinberger
2015-04-27 22:36 ` Ben Shelton
2015-04-27 22:42 ` Richard Weinberger
2015-04-27 22:53 ` Brian Norris
2015-04-27 22:57 ` Richard Weinberger
2015-04-27 23:10 ` Brian Norris
2015-04-27 23:15 ` Richard Weinberger
2015-04-27 23:19 ` Brian Norris
2015-04-27 23:23 ` Brian Norris
2015-04-28 2:48 ` punnaiah choudary kalluri
2015-04-28 3:22 ` Brian Norris [this message]
2015-04-28 3:44 ` punnaiah choudary kalluri
2015-04-28 14:03 ` Josh Cartwright
2015-04-28 16:19 ` punnaiah choudary kalluri
2015-05-08 21:26 ` Ben Shelton
2015-05-08 21:39 ` Brian Norris
2015-05-08 21:43 ` Richard Weinberger
2015-04-28 3:15 ` punnaiah choudary kalluri
2015-03-25 14:02 ` [PATCH 2/3] mtd: nand: Add support for raw access when using on-die ECC Richard Weinberger
2015-03-25 14:02 ` [PATCH 3/3] mtd: nand: Wire up on-die ECC support Richard Weinberger
2015-04-21 12:31 ` [RFC] On-die " Richard Weinberger
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=20150428032213.GI19571@brian-ubuntu \
--to=computersforpeace@gmail.com \
--cc=ben.shelton@ni.com \
--cc=boris.brezillon@free-electrons.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=punnaia@xilinx.com \
--cc=punnaiah.choudary.kalluri@xilinx.com \
--cc=richard@nod.at \
/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