On Fri, Jul 21, 2023 at 04:32:49PM +0800, Ming Lei wrote: > On Wed, Jul 19, 2023 at 11:01:14PM +0100, 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 block devices 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. > > > > This series is meant to open the discussion on how exactly the device tree > > schema for block devices and partitions may look like, and even if using > > the block layer to back the NVMEM device is at all the way to go -- to me > > it seemed to be a good solution because it will be reuable e.g. for NVMe. > > Just wondering why you don't use request_firmware() in drivers which consume > the data, then the logic can be moved out of kernel, and you needn't to deal > with device tree & block device. > > Or Android doesn't support udev and initrd? It does support initrd, but not really udev last I looked. But it does allow request_firmware() to be called at boot time, so yes, finding out why that isn't used here would be good. thanks, greg k-h
