All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: dedekind1@gmail.com
Cc: David Woodhouse <dwmw2@infradead.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Kevin Cernekee <cernekee@gmail.com>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/2] mtd: nand: renumber conflicting BBT flags
Date: Sat, 02 Apr 2011 01:04:05 -0700	[thread overview]
Message-ID: <4D96D875.9000809@gmail.com> (raw)
In-Reply-To: <1301576306.2828.68.camel@localhost>

Hello,

On 3/31/2011 5:58 AM, Artem Bityutskiy wrote:
> Hmm, it seems that the issue is that flags which belong to the same
> "space" should be in a single file. AFAICS, we have 2 spaces:
> 
> 1. Chip flags
> 2. BBT flags
> 
> They are 2 different things. But some of the flags are shared. And this
> is quite subtle thing.
> 
> What I think we should do instead is to avoid sharing the same symbolic
> constant between 2 different spaces. Is this possible?

I'm not quite sure. Many of the "shared" options go into the
nand_chip.options field only so that they can later be copied to a
nand_bbt_descr.options field. I think this is only out of convenience so
that we can detect chip-based BBT options like 'scan 2nd page' before we
have actually allocated and assigned our bbt descriptors. For these
flags, we can use a new field in nand_chip, like a
"nand_chip.bbm_options". Then, many shared flags would really become
"early BBT flags" that could safely be copied over without conflict.

Does this make any sense or are there holes in my idea here? I can try
an RFC patch soon if that would help.

Thanks,
Brian

  reply	other threads:[~2011-04-02  8:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-19  4:53 [PATCH 1/2] mtd: nand: renumber conflicting BBT flags Brian Norris
2011-03-19  4:53 ` [PATCH 2/2] mtd: nand: dynamic allocation of flash-based BBT structs Brian Norris
2011-03-31 12:58 ` [PATCH 1/2] mtd: nand: renumber conflicting BBT flags Artem Bityutskiy
2011-04-02  8:04   ` Brian Norris [this message]
2011-04-04  7:52     ` Artem Bityutskiy
2011-04-20  7:13       ` [RFC] mtd: nand: separate chip options / bbt_options Brian Norris
2011-04-22  8:02         ` Artem Bityutskiy
2011-05-25 18:15           ` Brian Norris
2011-05-26  8:04             ` Sebastian Andrzej Siewior
2011-05-31 17:25               ` Brian Norris
2011-04-04  7:58 ` [PATCH 1/2] mtd: nand: renumber conflicting BBT flags 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=4D96D875.9000809@gmail.com \
    --to=computersforpeace@gmail.com \
    --cc=bigeasy@linutronix.de \
    --cc=cernekee@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /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.