All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alessandro Rubini <rubini-list@gnudd.com>
To: linux-mtd@lists.infradead.org
Cc: STEricsson_nomadik_linux@list.st.com
Subject: RFC: nand and onenand can't coexist
Date: Sun, 20 Sep 2009 19:01:31 +0200	[thread overview]
Message-ID: <20090920170130.GA19668@mail.gnudd.com> (raw)

While testing the nomadik-onenand patch as applied by
dwmw2 to the mtd-2.6 git tree, I found that I can't declare
both a nand and onenand platform device in the same file.

The problem arises from the new platform_data for onenand, which
requires me to include <linux/mtd/onenand.h> in the same
file where I include <linux/mtd/nand.h>.

There are two errors reported:

* onenand_state_t and nand_state_t define the same enums,
  but with different values

* struct nand_bbt_descr and other material is defined both
  in nand.h and bbm.h.

For the latter, including bbm.h from nand.h, removing duplicates,
should work file (I'm going to try it right now).

The former is more of an issue, moreso because the same values
(FL_READY and such) are defined in <mtd/flashchip.h> as well.
Shouldn't they be rather unified?

A quick grep shows that

* nand_state_t is defined by ./include/linux/mtd/nand.h
  and never used.

* onenand_state_t is defined by ./include/linux/mtd/onenand.h
  and never used

* flstate_t is defined in ./include/linux/mtd/flashchip.h
  and used in a few places.

Should I try to unify things in order to allow OneNand and Nand
coexist in the same board source file and remove duplicates?

I'm going to work on the problem anyways, I just don't know
if patches in this direction are acceptable or not.

thanks
/alessandro

             reply	other threads:[~2009-09-20 17:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-20 17:01 Alessandro Rubini [this message]
2009-09-20 21:18 ` [PATCH 0/3] Allow Nand and OneNand to coexist Alessandro Rubini
2009-09-20 21:27   ` Alessandro Rubini
2009-09-20 21:27   ` Alessandro Rubini

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=20090920170130.GA19668@mail.gnudd.com \
    --to=rubini-list@gnudd.com \
    --cc=STEricsson_nomadik_linux@list.st.com \
    --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.