linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mike Dunn <mikedunn@newsguy.com>
To: dedekind1@gmail.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Scott Branden <sbranden@broadcom.com>,
	Wan ZongShun <mcuos.com@gmail.com>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Manuel Lauss <manuel.lauss@googlemail.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	linux-mtd@lists.infradead.org, Ralf Baechle <ralf@linux-mips.org>,
	Jiandong Zheng <jdzheng@broadcom.com>,
	Andres Salomon <dilinger@queued.net>,
	Olof Johansson <olof@lixom.net>, Jamie Iles <jamie@jamieiles.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Vimal Singh <vimal.newwork@gmail.com>
Subject: Re: [PATCH 1/5] mtd api changed to return bitflips on read operations
Date: Thu, 01 Dec 2011 03:22:22 -0800	[thread overview]
Message-ID: <4ED7636E.7010307@newsguy.com> (raw)
In-Reply-To: <1322730506.2332.30.camel@koala>

On 12/01/2011 01:08 AM, Artem Bityutskiy wrote:
> On Tue, 2011-11-29 at 14:40 +0100, Thomas Petazzoni wrote:
>> Also, another option is to allow max_bitflips to be NULL, which would
>> simplify things such as :
> Yes, I vote for this solution.


Yes, this was an dumb oversight on my part.  Will implement this as well.

I replied to Thomas' post, but the reply was flagged for human review by the ML
due to "suspicious header".  Probably because I had to read the original post
from the ML archives and paste it into my post because Thomas' post never made
it to my inbox for some reason.  Having email problems...


>> Another question: is the max_bitflips information sufficient (i.e on a
>> large read with multiple pages, you will only get the value for the
>> worst page) ? Don't you need the bitflip count on a per-page basis ?
> I do not think we need accurate per-page information.
>
>


My thought as well.

Should the patchset be combined into one patch?  Are separate, interdependent
patches ill-advised?

Thanks,
Mike

  reply	other threads:[~2011-12-01 11:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29  1:01 [PATCH 1/5] mtd api changed to return bitflips on read operations Mike Dunn
2011-11-29 13:40 ` Thomas Petazzoni
2011-12-01  9:08   ` Artem Bityutskiy
2011-12-01 11:22     ` Mike Dunn [this message]
2011-12-01 11:38       ` Artem Bityutskiy
2011-12-01 12:41         ` Mike Dunn
2011-12-01  8:49 ` Artem Bityutskiy
2011-12-01 11:06   ` Mike Dunn

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=4ED7636E.7010307@newsguy.com \
    --to=mikedunn@newsguy.com \
    --cc=computersforpeace@gmail.com \
    --cc=dbaryshkov@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dilinger@queued.net \
    --cc=dwmw2@infradead.org \
    --cc=haojian.zhuang@gmail.com \
    --cc=jamie@jamieiles.com \
    --cc=jdzheng@broadcom.com \
    --cc=kyungmin.park@samsung.com \
    --cc=lars@metafoo.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=manuel.lauss@googlemail.com \
    --cc=mcuos.com@gmail.com \
    --cc=olof@lixom.net \
    --cc=ralf@linux-mips.org \
    --cc=robert.jarzmik@free.fr \
    --cc=sbranden@broadcom.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=vimal.newwork@gmail.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).