[PATCH v2 0/2] mtd: devices: Qualcomm SCM storage support

[Miquel Raynal]

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