linux-kernel - Re: [PATCH v4 0/4] block: preparations for NVMEM provider

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: <5ac45dc2-f434-4ec3-9f9a-dab6bb029deb@kernel.dk>
Date: Thu, 27 Jun 2024 16:15:25 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Daniel Golle <daniel@...rotopia.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
 Hauke Mehrtens <hauke@...ke-m.de>, Felix Fietkau <nbd@....name>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Dave Chinner <dchinner@...hat.com>, Jan Kara <jack@...e.cz>,
 Christian Brauner <brauner@...nel.org>,
 Thomas Weißschuh <linux@...ssschuh.net>,
 Al Viro <viro@...iv.linux.org.uk>, Li Lingfeng <lilingfeng3@...wei.com>,
 Christian Heusel <christian@...sel.eu>, Min Li <min15.li@...sung.com>,
 Avri Altman <avri.altman@....com>, Adrian Hunter <adrian.hunter@...el.com>,
 Hannes Reinecke <hare@...e.de>, Mikko Rapeli <mikko.rapeli@...aro.org>,
 Yeqi Fu <asuk4.q@...il.com>, Victor Shih <victor.shih@...esyslogic.com.tw>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 Li Zhijian <lizhijian@...itsu.com>,
 "Ricardo B. Marliere" <ricardo@...liere.net>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
 linux-block@...r.kernel.org
Subject: Re: [PATCH v4 0/4] block: preparations for NVMEM provider

On 6/27/24 2:49 PM, Daniel Golle wrote:
> On embedded devices using an eMMC it is common that one or more (hw/sw)
> partitions on the eMMC are used to store MAC addresses and Wi-Fi
> calibration EEPROM data.
> 
> Typically the NVMEM framework is used to have kernel drivers read and
> use binary data from EEPROMs, efuses, flash memory (MTD), ...
> 
> Using references to NVMEM bits in Device Tree allows the kernel to
> access and apply e.g. the Ethernet MAC address, which can be a requirement
> for userland to come up (e.g. for nfsroot).
> 
> The goal of this series is to prepare the block subsystem to allow for
> the implementation of an NVMEM provider similar to other types of
> non-volatile storage, so the same approach already used for EEPROMs, MTD
> (raw flashes) and UBI-managed NAND can also be used for devices storing
> those bits on an eMMC.
> 
> Define a device tree schema for block devices and partitions on them,
> which (similar to how it now works also for UBI volumes) can be matched
> by one or more properties.
> 
> Also add a simple notification API for other subsystems to be notified
> about additions and removals of block devices, which is going to be used
> by the block-backed NVMEM provider.
> 
> Overall, this enables uniform handling across practially all flash
> storage types used for this purpose (MTD, UBI, and soon also MMC or and
> in future maybe also other block devices).

2-4 look fine to me now, but I don't know anything about the device
bindings so someone qualified should review that before it gets queued
up.

-- 
Jens Axboe