On Fri, Mar 22, 2024 at 10:52:17AM -0700, Bart Van Assche wrote: > On 3/21/24 12:31, 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. > > > > Implement an NVMEM provider backed by a block device as typically the > > NVMEM framework is used to have kernel drivers read and use binary data > > from EEPROMs, efuses, flash memory (MTD), ... > > > > In order to be able to reference hardware partitions on an eMMC, add code > > to bind each hardware partition to a specific firmware subnode. > > > > Overall, this enables uniform handling across practially all flash > > storage types used for this purpose (MTD, UBI, and now also MMC). > > > > As part of this series it was necessary to 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. > > Since this patch series adds code that opens partitions and reads > from partitions, can that part of the functionality be implemented in > user space? There is already a mechanism for notifying user space about > block device changes, namely udev. No. Because it has to happen (e.g. for nfsroot to work) before userland gets initiated: Without Ethernet MAC address (which if often stored at some raw offset on a partition or hw-partition of an eMMC), we don't have a way to use nfsroot (because that requires functional Ethernet), hence userland won't come up. It's a circular dependency problem which can only be addressed by making sure that everything needed for Ethernet to come up is provided by the kernel **before** rootfs (which can be nfsroot) is mounted.
