public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Mike Dunn <mikedunn@newsguy.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Ivan Djelic <ivan.djelic@parrot.com>,
	dwmw2@infradead.org, Sascha Hauer <s.hauer@pengutronix.de>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: flash bbt broken due to unitialized bitflip_threshold?
Date: Mon, 25 Jun 2012 10:44:59 -0700	[thread overview]
Message-ID: <4FE8A39B.6060409@newsguy.com> (raw)
In-Reply-To: <CAN8TOE90sB0-ZHZPX4+ASUDBCSRHgumVqDu0BOrcphyijm6Xgw@mail.gmail.com>

On 06/22/2012 01:39 PM, Brian Norris wrote:
> On Sun, Jun 10, 2012 at 12:08 AM, Shmulik Ladkani
> <shmulik.ladkani@gmail.com> wrote:
>> To summarize, return value of the 'mtd_read_oob()' API is
>> inconsistent (sometimes max_bitflips, other times EUCLEAN), and does not
>> adhere to return code policy of 'mtd_read()' - return EUCLEAN to the users,
>> they're not interested with internals such as max_bitflips.
>>
>> This might affect users of 'mtd_read_oob()' which might falsely think
>> the OOB read has failed.
>>
>> Mike, care to take a look and amend if necessary?
>> I think this needs to be fixed pre v3.5 as well.
> 
> Mike, are you planning on handling this?
> 
> I think it would be safe to basically C&P the max_bitflips code from
> mtd_read() into mtd_read_oob(). This would simply pass through the
> EUCLEAN that may be returned for OOB-only case (only for my driver?),
> and it would translate the 'ret_code > 0' case properly for data+OOB
> reads. I'll resend officially if this looks OK. Or I'll defer to Mike
> if he's working on this.


I'm sorry Brian, I missed Shmulik's post and thought this issue was put to bed
with the patch that initialized bitflip_threshold before the nand_scan_tail()
call.

I will take a look at your patch set that addresses this.  Sorry for dropping
the ball.

Mike

  reply	other threads:[~2012-06-25 17:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-05 22:06 flash bbt broken due to unitialized bitflip_threshold? Sascha Hauer
2012-06-06  9:50 ` Shmulik Ladkani
2012-06-06 13:30   ` Artem Bityutskiy
2012-06-06 15:15     ` Shmulik Ladkani
2012-06-06 15:46       ` Artem Bityutskiy
2012-06-06 16:08         ` Shmulik Ladkani
2012-06-06 17:55         ` Ivan Djelic
2012-06-07  7:36           ` Artem Bityutskiy
2012-06-07 14:02             ` Shmulik Ladkani
2012-06-07 17:34             ` Mike Dunn
2012-06-07 21:07               ` Shmulik Ladkani
2012-06-10  7:08               ` Shmulik Ladkani
2012-06-22 20:39                 ` Brian Norris
2012-06-25 17:44                   ` Mike Dunn [this message]
2012-06-07  7:43           ` Artem Bityutskiy

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=4FE8A39B.6060409@newsguy.com \
    --to=mikedunn@newsguy.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    /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