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
next 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.