All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Tom Isaacson <Tom.Isaacson@navico.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Exposing NAND chip information
Date: Sun, 22 Apr 2012 17:44:50 +0300	[thread overview]
Message-ID: <1335105890.28267.27.camel@brekeke> (raw)
In-Reply-To: <B36E81988B048A4FA3600EDE585F756BD0EBD2@EXCH02-AKLNZ.MARINE.NET.INT>

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

On Sun, 2012-04-15 at 23:20 +0000, Tom Isaacson wrote:
> Hi,
> 
> Our production software needs to record the NAND chip type used in
> production so we have a record in case we get problems later. The
> information we need is printed out by nand_get_flash_type(), e.g.:
>   NAND device: Manufacturer ID: 0x98, Chip ID: 0xd1 (Toshiba NAND
> 128MiB 3,3V 8-bit)
> My plan is to add some files to the /sys tree to expose this
> information. But the only part of that information stored is the
> device name, in mtd_info.name. Is there any reason why I shouldn't add
> the manufacturer name and ID and the chip ID to mtd_info so they can
> be accessed later on? Or should I add them to mxd_mtd_s (in
> nand_base.c) and keep it local?
> 
If you have a need to have them in mtd_info - probably you can add
those. Just add/document a way to detect that the chip does not have
this data. E.g., all zeroes or -1. I mean, NORs might not have the IDs.

> Also, when I add the files to the /sys tree is there any naming
> convention I should follow? I was going to copy the way the eMMC
> device does it:
>   manfid - Manufacturer ID
>   devid - Chip ID
>   manf_name - Manufacturer name
>   dev_name - Chip name

Should we put all ID's to the same file instead? Or at lease
manfid/manf_name and devid/dev_name pairs to waste less RAM because each
sysfs file cunsumes several KiBs of RAM AFAIR (struct inode alone is
several KiB). Also if you add sysfs files - do not forget to document
them id Documentation/ABI and CC Greg KH.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2012-04-22 14:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-15 23:20 Exposing NAND chip information Tom Isaacson
2012-04-16  6:59 ` Florian Fainelli
2012-04-16 23:51   ` Tom Isaacson
2012-04-17  9:39     ` Florian Fainelli
2012-04-22 14:44 ` Artem Bityutskiy [this message]
2012-04-22 23:40   ` Tom Isaacson
2012-04-27 14:12     ` 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=1335105890.28267.27.camel@brekeke \
    --to=dedekind1@gmail.com \
    --cc=Tom.Isaacson@navico.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.