From: Artem Bityutskiy <dedekind1@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>,
Huang Shijie <b32955@freescale.com>
Cc: MTD Maling List <linux-mtd@lists.infradead.org>
Subject: [PATCH 2/2] mtd: nand: provision full ID support
Date: Tue, 5 Mar 2013 16:39:36 +0200 [thread overview]
Message-ID: <1362494376-1588-2-git-send-email-dedekind1@gmail.com> (raw)
In-Reply-To: <1362494376-1588-1-git-send-email-dedekind1@gmail.com>
From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Up until now we identified NAND chips by the 'device ID' part of the full chip
ID array, which is the second full ID array byte. However, the newest flashes
use the same device ID for chips with identical page and eraseblock sizes, but
different OOB sizes. And unfortunately, it is not clear if there is a
"standard" way to fetch the OOB size from chip's full ID array. Here is an
example:
Toshiba TC58NVG2S0F: 0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08
Toshiba TC58NVG3S0F: 0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08
The first one is a 512MiB NAND chip with 4KiB NAND pages, 256KiB eraseblock
size and 224 bytes OOB. The second one is a 1GiB NAND chip with the same page
and eraseblock sizes, but with 232 bytes OOB.
This means that we have to store full ID in our NAND flashes table in order to
distinguish between these 2.
This patch adds the 'id[8]' field to the 'struct nand_flash_dev' structure, and
it makes it to be a part of anonymous union, where the second member is a
structure containing the 'mfr_id' and 'dev_id' bytes. The union makes sure that
'mfr_id' refers the same RAM address as 'id[0]' and 'dev_id' refers the same
RAM address as 'id[1]'. The only motivation for the union is an assumption that
'type->dev_id' is more readable than 'type->id[1]'.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
include/linux/mtd/nand.h | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 7ecc6d8..370f4f0 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -567,6 +567,11 @@ struct nand_chip {
* struct nand_flash_dev - NAND Flash Device ID Structure
* @name: a human-readable name of the NAND chip
* @dev_id: the device ID (the second byte of the full chip ID array)
+ * @mfr_id: manufecturer ID part of the full chip ID array (refers the same
+ * memory address as @id[0])
+ * @dev_id: device ID part of the full chip ID array (refers the same memory
+ * address as @id[0])
+ * @id: full device ID array
* @pagesize: size of the NAND page in bytes; if 0, then the real page size (as
* well as the eraseblock size) is determined from the extended NAND
* chip ID array)
@@ -576,7 +581,13 @@ struct nand_chip {
*/
struct nand_flash_dev {
char *name;
- int dev_id;
+ union {
+ struct {
+ uint8_t mfr_id;
+ uint8_t dev_id;
+ };
+ uint8_t id[8];
+ };
unsigned long pagesize;
unsigned long chipsize;
unsigned long erasesize;
--
1.7.10.4
next prev parent reply other threads:[~2013-03-05 14:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-05 14:39 [PATCH 1/2] mtd: nand_ids: introduce helper macros Artem Bityutskiy
2013-03-05 14:39 ` Artem Bityutskiy [this message]
2013-03-05 14:49 ` [PATCH 2/2] mtd: nand: provision full ID support Artem Bityutskiy
2013-03-06 8:00 ` Huang Shijie
2013-03-06 8:47 ` Artem Bityutskiy
2013-03-06 7:15 ` [PATCH 1/2] mtd: nand_ids: introduce helper macros 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=1362494376-1588-2-git-send-email-dedekind1@gmail.com \
--to=dedekind1@gmail.com \
--cc=b32955@freescale.com \
--cc=computersforpeace@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox