All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mike Dunn <mikedunn@newsguy.com>
Cc: Scott Branden <sbranden@broadcom.com>,
	Joern Engel <joern@logfs.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	linux-mtd@lists.infradead.org,
	Jiandong Zheng <jdzheng@broadcom.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>
Subject: Re: [PATCH] MTD: drivers return bitlip info to mtd on read
Date: Tue, 27 Dec 2011 22:57:00 +0200	[thread overview]
Message-ID: <1325019422.2292.8.camel@koala> (raw)
In-Reply-To: <4EFA29E4.1020803@newsguy.com>

On Tue, 2011-12-27 at 12:26 -0800, Mike Dunn wrote:
> On 12/27/2011 12:33 AM, Artem Bityutskiy wrote:
> > On Mon, 2011-12-26 at 11:38 -0800, Mike Dunn wrote:
> >> This patch changes the meaning of the value returned by the read() and
> >> read_oob() mtd driver methods.  Previously, absent a hard error, these functions
> >> returned either -EUCLEAN (one or more bitflips were corrected) or 0 (no
> >> bitflips).  Drivers now return, absent a hard error, the maximum number of
> >> bitflips that were corrected on any one page.  
> >>
> >> This change is made possible by the fact that all calls to the driver methods
> >> now go through mtd wrapper functions.  The values returned by those wrapper
> >> functions have not changed, nor have their meaning.  Only the values returned to
> >> the mtd wrappers by the driver have changed.
> >>
> >> Tested with nandsim and onenand_sim.  The two drivers that were modified were
> >> compile-tested only.
> >>
> >> Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
> > Hi, I am not sure using the return code is a good way for this.
> 
> 
> OK.  It was a little kludgey, but had the advantage of touching very few drivers
> and leaving the existing function prototypes unchanged.

May be you are right, I need to think. But this is only true when you
are 100% sure no one uses the function pointers directly. The very
reliable way is to rename them, so the offenders would end up with a
compilation error. I am also thinking about out-of-tree drivers.

But I am planning to add leading "_" symbol to the function pointers
(e.g., mtd->read() => mtd->_read()). So this anyway will touch a lot of
code. And then this argument is probably not too strong anymore.

Anyway, let me emphasize that this should not be a show-stopper for
you - proceed with your DoC work meanwile. I'll try to come up with the
changes this week, but no promises, then I'll create a temporary branch
in my tree and we can use it till the end of the 3.3 merge window.

Artem.

      reply	other threads:[~2011-12-27 20:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-26 19:38 [PATCH] MTD: drivers return bitlip info to mtd on read Mike Dunn
2011-12-27  8:33 ` Artem Bityutskiy
2011-12-27 20:26   ` Mike Dunn
2011-12-27 20:57     ` Artem Bityutskiy [this message]

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=1325019422.2292.8.camel@koala \
    --to=dedekind1@gmail.com \
    --cc=jdzheng@broadcom.com \
    --cc=joern@logfs.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.com \
    --cc=robert.jarzmik@free.fr \
    --cc=sbranden@broadcom.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 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.