Exposing NAND chip information

Exposing NAND chip information

[Tom Isaacson]

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?

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

Thanks for any help.

Tom Isaacson
Senior Software Developer
Navico

Re: Exposing NAND chip information

[Florian Fainelli]

Hi,

On Sunday 15 April 2012 23:20:25 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?
> 
> 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

I have the exact same requirement and cooked up a patch to do this for NAND:
http://patchwork.ozlabs.org/patch/94407/

however, to be complete it would also need to expose such informations for SPI 
and NOR flashes, which I have not done yet.
--
Florian

RE: Exposing NAND chip information

[Tom Isaacson]

> I have the exact same requirement and cooked up a patch to do this for NAND:
> http://patchwork.ozlabs.org/patch/94407/

Ah, your patch shows you've added the sysfs files in mtdcore.c, which means they'll show up in:
/sys/class/mtd/..
The code I've done adds them in mxc_nd2.c (the device I have) so they appear in:
/sys/devices/platform/mxc_nandv2_flash.0/..
Obviously this only works for one type of flash right now, but I was thinking of extending all the separate uses of DEVICE_ATTR and manage_sysfs_files() to call back to a generic sysfs function in nand_base.c so these new parameters appear for all NAND devices.
I can't find anything online that gives a guide to where files should be added to sysfs - is there such a thing, or do people just make it up as they go along?

> however, to be complete it would also need to expose such informations for SPI
> and NOR flashes, which I have not done yet.

I don't have access to those devices so I can't test any code I might attempt.

Tom

Re: Exposing NAND chip information

[Florian Fainelli]

Hi Tom,

Le 04/17/12 01:51, Tom Isaacson a écrit :
>> I have the exact same requirement and cooked up a patch to do this for NAND:
>> http://patchwork.ozlabs.org/patch/94407/
>
> Ah, your patch shows you've added the sysfs files in mtdcore.c, which means they'll show up in:
> /sys/class/mtd/..

Yes, when I first asked what was the best place to add those attributes, 
I initially wanted to create something like /sys/class/mtd/nand0 or such 
and put attributes there, but Artem preferred having them in 
/sys/class/mtd/mtd<N>/

> The code I've done adds them in mxc_nd2.c (the device I have) so they appear in:
> /sys/devices/platform/mxc_nandv2_flash.0/..
> Obviously this only works for one type of flash right now, but I was thinking of extending all the separate uses of DEVICE_ATTR and manage_sysfs_files() to call back to a generic sysfs function in nand_base.c so these new parameters appear for all NAND devices.
> I can't find anything online that gives a guide to where files should be added to sysfs - is there such a thing, or do people just make it up as they go along?
>
>> however, to be complete it would also need to expose such informations for SPI
>> and NOR flashes, which I have not done yet.
>
> I don't have access to those devices so I can't test any code I might attempt.

I do, it's just that I have been lazy on working again on this.
--
Florian

Re: Exposing NAND chip information

[Artem Bityutskiy]

[-- 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 --]

RE: Exposing NAND chip information

[Tom Isaacson]

> 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.
I think zeroes would make more sense.

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

The documentation for sysfs (http://lxr.linux.no/linux+v3.3.2/Documentation/filesystems/sysfs.txt) says:
"Attributes should be ASCII text files, preferably with only one value per file. It is noted that it may not be efficient to contain only one value per file, so it is socially acceptable to express an array of values of the same type."
So if we want to combine we should do it the first way - both IDs in one file, both strings in another:
  id - Manufacturer and Chip ID (tab separated)
  name - Manufacturer and Chip name (tab separated)

Tom

RE: Exposing NAND chip information

[Artem Bityutskiy]

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

On Sun, 2012-04-22 at 23:40 +0000, Tom Isaacson wrote:
> The documentation for sysfs (http://lxr.linux.no/linux
> +v3.3.2/Documentation/filesystems/sysfs.txt) says:
> "Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only one
> value per file, so it is socially acceptable to express an array of
> values of the same type."
> So if we want to combine we should do it the first way - both IDs in
> one file, both strings in another:
>   id - Manufacturer and Chip ID (tab separated)
>   name - Manufacturer and Chip name (tab separated)

I think that would not make sense to combine ids and names. I think that
is a general recommendation which should be go through the common sense
filter. E.g., there are many "dev" attributes in "major:minor" format.
Or look at the 'uevent' attributes contents. Or "resource" pci
subsystems' files.

-- 
Best Regards,
Artem Bityutskiy

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