linux-kernel - Re: [PATCH v2] mtd: core: Add nand_id sysfs attribute for NAND devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <874irrrpbp.fsf@bootlin.com>
Date: Wed, 22 Oct 2025 16:19:54 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: jayxu1990@...il.com
Cc: Richard Weinberger <richard@....at>,  Vignesh Raghavendra
 <vigneshr@...com>,  linux-mtd@...ts.infradead.org,
  linux-kernel@...r.kernel.org,  avnerkhan@...xas.edu,
  rdlee.upstream@...il.com,  kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] mtd: core: Add nand_id sysfs attribute for NAND devices

Hello,

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

> From: Jay Xu <jayxu1990@...il.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@...el.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510120356.STGKDkA5-lkp@intel.com/
> Signed-off-by: Jay Xu <jayxu1990@...il.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