linux-kernel - Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

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] [day] [month] [year] [list]

Message-ID: <87jywthpsj.fsf@bootlin.com>
Date: Tue, 03 Feb 2026 15:20:28 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Junhao Xie <bigfoot@...xa.com>
Cc: Bjorn Andersson <andersson@...nel.org>,  Konrad Dybcio
 <konradybcio@...nel.org>,  Richard Weinberger <richard@....at>,  Vignesh
 Raghavendra <vigneshr@...com>,  linux-arm-msm@...r.kernel.org,
  linux-kernel@...r.kernel.org,  linux-mtd@...ts.infradead.org,  Xilin Wu
 <sophon@...xa.com>
Subject: Re: [PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support


>>> For something like the "DPP" partition, I think it's better to access it
>>> from userspace than from kernel.
>> If it's a MAC address that you are accessing, direct userspace does not
>> sound like a good fit. If I may, NVMEM cells are there exactly for this
>> purpose: identifying the content of a subpart of a storage device in a
>> storage agnostic way. The NVMEM cells are made available to in-kernel
>> drivers (ie. network devices have all the infrastructure to get the MAC
>> address from there) and their content is also exposed to userspace
>> through sysfs now.
>
> Qualcomm's SPI-NOR boot firmware uses a GPT partition table. The "DPP"
> partition contains a FAT file system, and the MAC address is stored in
> one of these files.
>
> Because the data is stored inside a filesystem rather than at a fixed
> offset, it does not fit well with the NVMEM model, which assumes simple
> offset-based access.

Not anymore, there are nvmem layouts now that are much more
flexible, so if a network driver shall get this MAC address, it is still
doable.

Otherwise there is no such need, and in the case of a file in a FAT
filesystem, I guess it is preferable to use mtdblock/ubiblock in order
to expose a block device and mount it from userspace.

Please note that exposing a FAT filesystem on top of a SPI NOR is very
inappropriate. FAT is a block filesystem, not aware of all the MTD
specificities (like bad blocks).

Cheers,
Miquèl