public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: jayxu1990@gmail.com
Cc: Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	 avnerkhan@utexas.edu, rdlee.upstream@gmail.com,
	 kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2] mtd: core: Add nand_id sysfs attribute for NAND devices
Date: Wed, 22 Oct 2025 16:19:54 +0200	[thread overview]
Message-ID: <874irrrpbp.fsf@bootlin.com> (raw)
In-Reply-To: <20251014192455.4007534-1-jayxu1990@gmail.com> (jayxu's message of "Wed, 15 Oct 2025 03:24:55 +0800")

Hello,

On 15/10/2025 at 03:24:55 +08, jayxu1990@gmail.com wrote:

> From: Jay Xu <jayxu1990@gmail.com>
>
> [Problem]
> Currently, NAND devices do not expose their NAND ID through sysfs,
> making it difficult for userspace applications to identify the specific
> NAND flash chip in use. For supply management reasons, electronics
> products are typically manufactured with multiple storage device
> suppliers, creating a need to identify which storage device is used
> on a particular product. The NAND ID is a semi-unique identifier that can
> be used to determine chip-specific characteristics such as maximum P/E
> cycles, which is essential for NAND health monitoring and wear leveling
> algorithms.
>
> [Solution]
> This patch adds a new 'nand_id' sysfs attribute that:
>
> 1. Exposes the full NAND ID (typically 5-8 bytes) in hexadecimal format
> 2. Only appears on physical NAND devices (MTD_NANDFLASH/MTD_MLCNANDFLASH)
> 3. Is hidden on virtual MTD devices
> 4. Reads from the master device to ensure consistent ID across partitions
> 5. Handles on-demand ID reading if not already populated during probe
>
> The implementation uses a separate attribute group with visibility control
> to avoid affecting existing MTD sysfs attributes. All NAND partitions
> from the same physical chip will show the same ID, as expected.
>
> The NAND-specific code is conditionally compiled with CONFIG_MTD_RAW_NAND
> to ensure clean builds when raw NAND support is not enabled.
>
> This enables userspace tools to reliably identify NAND chips for
> health monitoring, bad block management, and device-specific
> optimizations.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510120356.STGKDkA5-lkp@intel.com/
> Signed-off-by: Jay Xu <jayxu1990@gmail.com>
> ---

I haven't reviewed the code yet, but at a first glance I would not be
opposed to it. I remember though we already had some kind of similar
discussion and IIRC we declined (I cannot remember why nor find any
relevant link).

Richard, does that ring a bell?

If we go the route of printing an ID, maybe we should make sure the ID
is always populated (we always read it at probe time) so we do not need
to re-read it later. Also, we should probably store it somewhere in the
NAND core and not make it raw NAND specific as SPI NANDs will likely
suffer from the same issue at some point.

Thanks,
Miquèl

  reply	other threads:[~2025-10-22 14:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-07 22:40 [PATCH] mtd: core: Add nand_id sysfs attribute for NAND devices jayxu1990
2025-10-11 20:03 ` kernel test robot
2025-10-14 19:24 ` [PATCH v2] " jayxu1990
2025-10-22 14:19   ` Miquel Raynal [this message]
     [not found]     ` <CABcGJDxxGSDVc9TPcTMR_7abreBchHEKHsqtfZVQ5m+0nFhJ1A@mail.gmail.com>
2025-10-23  6:54       ` Miquel Raynal

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=874irrrpbp.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=avnerkhan@utexas.edu \
    --cc=jayxu1990@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=lkp@intel.com \
    --cc=rdlee.upstream@gmail.com \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /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